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á.
# Migração de banco de dados homogênea para SQL Server
AWS oferece a capacidade de executar bancos de dados do SQL Server em um ambiente de nuvem. Para desenvolvedores e administradores de banco de dados, executar o banco de dados do SQL Server na AWS nuvem é muito semelhante à execução do banco de dados do SQL Server em um data center. Esta seção descreve as opções para migrar seu banco de dados do SQL Server de um ambiente on-premises ou de um data center para a nuvem AWS .
AWS oferece três opções para executar o SQL Server em AWS, conforme descrito na tabela a seguir.
****
| Opção | Destaques | Mais informações |
| --- | --- | --- |
| SQL Server no Amazon RDS | Serviço gerenciado que fornece fácil provisionamento e licenciamento, econômico, fácil de configurar, gerenciar e manter. | Seção [Amazon RDS para SQL Server](rds-sql.md) |
| SQL Server no Amazon RDS Custom | Serviço gerenciado, mas você retém os direitos administrativos do banco de dados e do sistema operacional subjacente. | Seção [Amazon RDS Custom for SQL Server](rds-custom-sql.md) |
| SQL Server no Amazon EC2 | Autogerenciado, oferece total controle e flexibilidade. | Seção [Amazon EC2 para SQL Server](ec2-sql.md) |
| SQL Server na VMware nuvem em AWS | Configure, escale e opere suas cargas de trabalho do SQL Server no VMware Cloud on AWS e integre com Directory Service o Active Directory Connector e o Amazon S3. | VMware Seção [Cloud on AWS para SQL Server](vmware-sql.md) |
**Aviso**
Em 30 de abril de 2024, o VMware Cloud on não AWS é mais revendido por AWS ou por seus parceiros de canal. O serviço continuará disponível por meio da Broadcom. Recomendamos que você entre em contato com seu AWS representante para obter detalhes.
Seus requisitos de aplicativos, atributos de banco de dados, funcionalidade, capacidade de crescimento e complexidade geral da arquitetura determinarão qual opção escolher. Se você estiver migrando vários bancos de dados do SQL Server para AWS, alguns deles podem ser ideais para o Amazon RDS, enquanto outros podem ser mais adequados para execução direta no Amazon EC2. Você pode ter bancos de dados que estão sendo executados na edição SQL Server Enterprise, mas são uma boa opção para a edição SQL Server Standard. Talvez você também queira modernizar seu banco de dados SQL Server executado no Windows para ser executado em um sistema operacional Linux para economizar custos e licenças. Muitos AWS clientes executam várias cargas de trabalho de banco de dados do SQL Server no Amazon RDS, Amazon EC2 e Cloud on. VMware AWS
**nota**
Você pode usar o Migration Hub Orchestrator para automatizar e orquestrar suas migrações de banco de dados do SQL Server para o Amazon EC2 ou o Amazon RDS usando backup e restauração nativos. Para obter mais informações, consulte a [Orquestrador do AWS Migration Hub seção](mho.md).
# Amazon RDS para SQL Server
O Amazon RDS para SQL Server é um serviço de banco de dados gerenciado que simplifica o provisionamento e o gerenciamento do SQL Server em AWS. O Amazon RDS facilita a configuração, a operação e a escala de implantações do SQL Server na nuvem. Com o Amazon RDS, você pode implantar várias versões do SQL Server (2014, 2016, 2017, 2019 e 2022) e edições (incluindo Express, Web, Standard e Enterprise) em minutos, com capacidade computacional econômica e redimensionável. Você pode provisionar instâncias de banco de dados do Amazon RDS para SQL Server com armazenamento SSD de uso geral ou SSD de IOPS provisionadas. (Para obter detalhes, consulte [Tipos de armazenamento do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html#Concepts.Storage) na AWS documentação.) O SSD de IOPS provisionado foi projetado para oferecer I/O desempenho rápido, previsível e consistente, além de ser otimizado para cargas de trabalho de banco de dados transacionais (OLTP) com uso intenso de E/S.
O Amazon RDS permite que você se concentre no desenvolvimento de aplicativos, pois gerencia tarefas demoradas de administração do banco de dados, incluindo provisionamento, backups, aplicação de patches de software, monitoramento e escalabilidade de hardware. O Amazon RDS para SQL Server também oferece implantações Multi-AZ e réplicas de leitura (para a edição SQL Server Enterprise) para fornecer alta disponibilidade, desempenho, escalabilidade e confiabilidade para workloads de produção.
## Quando escolher o Amazon RDS
O Amazon RDS para SQL Server é uma opção de migração quando:
+ Você quer se concentrar em seus negócios e aplicativos e cuidar de tarefas pesadas indiferenciadas, como provisionamento do banco de dados, gerenciamento de tarefas de backup e recuperação, gerenciamento de patches de segurança, pequenas atualizações de versões do SQL Server e gerenciamento de armazenamento. AWS
+ Você precisa de uma solução de banco de dados altamente disponível e quer aproveitar a replicação multi-AZ síncrona e automática oferecida pelo Amazon RDS, sem precisar configurar e manter manualmente o espelhamento de banco de dados, clusters de failover ou grupos de disponibilidade Always On.
+ Você quer pagar pela licença do SQL Server como parte do custo da instância por hora, em vez de fazer um grande investimento inicial.
+ O tamanho do seu banco de dados e as necessidades de IOPS são compatíveis com o Amazon RDS para SQL Server. Consulte [Amazon RDS DB Instance Storage](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) na AWS documentação para ver os limites máximos atuais.
+ Você não quer gerenciar backups ou point-in-time recuperações do seu banco de dados.
+ Você quer se concentrar em tarefas de alto nível, como ajuste de desempenho e otimização de esquemas, em vez da administração diária do banco de dados.
+ Você quer escalar o tipo de instância para mais ou para menos com base em seus padrões de workload sem se preocupar com as complexidades do licenciamento.
Depois de avaliar seus requisitos de banco de dados e projeto, se você decidir migrar para o Amazon RDS para SQL Server, consulte os detalhes fornecidos nas seções a seguir e analise [as melhores práticas de migração](best-practices.md) que discutiremos posteriormente neste guia.
Para conhecer os recursos, versões e opções do SQL Server atualmente suportados, consulte os recursos do [Amazon RDS for SQL Server](https://aws.amazon.com/rds/sqlserver/features/) no site[, Escolha entre AWS o Amazon EC2 e o Amazon](comparison.md) RDS, mais adiante neste guia[, e o Microsoft SQL Server no Amazon AWS RDS, na](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html) documentação. Se você estiver migrando para o Amazon RDS Custom, certifique-se de analisar [os requisitos e as limitações do Amazon RDS Custom para SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html).
## Alta disponibilidade
O Amazon RDS oferece alta disponibilidade e suporte a failover para bancos de dados implantados com a opção Multi-AZ. Quando você provisiona seu banco de dados com a opção Multi-AZ, o Amazon RDS automaticamente provisiona e mantém uma instância em espera síncrona em outra Zona de disponibilidade. O banco de dados primário replica os dados de forma síncrona para a instância em espera. Se ocorrerem problemas, o Amazon RDS repara automaticamente a instância não íntegra e restabelece a sincronização. Em caso de falha na infraestrutura ou interrupção da zona de disponibilidade, o Amazon RDS executa um failover automático para a instância em espera. O failover só ocorrerá se os bancos de dados de modo em espera e primário estiverem totalmente sincronizados. Como o endpoint permanece o mesmo para as instâncias primária e em espera, você pode retomar as operações do banco de dados assim que o failover for concluído, sem realizar uma intervenção manual. Os tempos de failover dependem do tempo necessário para completar o processo de recuperação. Transações grandes aumentam o tempo de failover.
O diagrama a seguir ilustra a opção de implantação Multi-AZ do Amazon RDS para SQL Server.
![\[Amazon RDS for SQL Server in a Multi-AZ configuration\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-rds-ha.png)
Quando você configura o SQL Server em uma configuração Multi-AZ, o Amazon RDS configura automaticamente a instância de banco de dados em espera usando espelhamento de banco de dados ou grupos de disponibilidade Always On, com base na versão do SQL Server que você implanta. As versões e edições específicas do SQL Server estão listadas na documentação do [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.html).
Em implantações Multi-AZ, operações como escalabilidade de instâncias ou atualizações de sistema, como aplicação de patches no sistema operacional (SO), são aplicadas primeiro na instância em espera, antes do failover automático da instância primária, para maior disponibilidade.
Devido à otimização de failover do SQL Server, determinadas workloads podem gerar maior carga de E/S na instância em espera do que na instância primária, especialmente em implantações de espelhamento de banco de dados. Essa funcionalidade pode resultar em maior IOPS na instância em espera. Recomendamos que você considere as necessidades máximas de IOPS das instâncias primária e de espera ao provisionar o tipo de armazenamento e o IOPS da sua instância de banco de dados Amazon RDS para SQL Server. Você também pode especificar `MultiSubnetFailover=True`, se o driver do cliente for compatível, para reduzir significativamente o tempo de failover.
### Limitações
+ A opção Multi-AZ não está disponível para as edições SQL Server Express e Web. Está disponível somente para as edições Standard e Enterprise do SQL Server.
+ Não é possível configurar a instância de banco de dado secundária para aceitar a atividade de leitura de banco de dados.
+ O Multi-AZ entre regiões não é compatível.
+ No Amazon RDS, você pode emitir um comando stop para uma instância de banco de dados autônoma e manter a instância em um estado parado para evitar cobranças computacionais. Você não pode interromper uma instância de banco de dados do Amazon RDS para SQL Server em uma configuração multi-AZ. Em vez disso, você pode encerrar a instância, tirar um snapshot final antes do encerramento e recriar uma nova instância do Amazon RDS a partir do snapshot quando precisar. Ou você pode remover primeiro a configuração Multi-AZ e depois interromper a instância. Depois de sete dias, sua instância interrompida será reiniciada para que qualquer manutenção pendente possa ser aplicada.
Para ver as limitações adicionais, consulte as [notas e recomendações de implantação Multi-AZ do Microsoft SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerMultiAZ.html#USER_SQLServerMultiAZ.Recommendations) na documentação do Amazon RDS.
## Réplicas de leitura
As réplicas de leitura fornecem escalabilidade e balanceamento de carga. Uma réplica de leitura do SQL Server é uma cópia física de uma instância de banco de dados Amazon RDS para SQL Server usada somente para fins de leitura. O Amazon RDS ajuda a reduzir a carga na instância de banco de dados primária ao transferir workload somente de leitura para a instância de banco de dados de réplica de leitura. As atualizações feitas à instância de banco de dados primária são copiadas de forma assíncrona na réplica de leitura.
Quando você solicita uma réplica de leitura, o Amazon RDS cria um snapshot da instância DB de origem e transfere esse snapshot para a réplica de leitura. Não há interrupção ao criar e excluir uma réplica de leitura. O Amazon RDS para SQL Server atualiza o banco de dados primário imediatamente após a atualização das réplicas de leitura, desconsiderando a janela de manutenção de uma réplica. Cada réplica de leitura vem com um endpoint separado que você usa para se conectar ao banco de dados da réplica de leitura.
O Amazon RDS para SQL Server facilita a criação de réplicas de leitura configurando grupos de disponibilidade Always On e mantendo conexões de rede seguras entre uma instância de banco de dados primário e suas réplicas de leitura.
Você pode configurar uma réplica de leitura na mesma AWS região do seu banco de dados principal ou em outra região. Você pode criar até cinco réplicas de leitura de uma instância de banco de dados de origem.
**nota**
As réplicas de leitura estão disponíveis somente com as seguintes versões e edições do SQL Server:
SQL Server 2017 Enterprise Edition 14.00.3049.1 ou posterior
SQL Server 2016 Enterprise Edition 13.00.5216.0 ou posterior
As versões e edições do SQL Server que oferecem suporte ao espelhamento de banco de dados para ambientes Multi-AZ não oferecem réplicas de leitura.
O diagrama a seguir ilustra uma instância de banco de dados Amazon RDS for SQL Server em um ambiente Multi-AZ com uma réplica de leitura em outra zona de disponibilidade na mesma região. AWS Nem todas as AWS regiões oferecem mais de duas zonas de disponibilidade, então você deve [verificar a região](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) que planeja usar antes de adotar essa estratégia.
![\[Amazon RDS for SQL Server with a read replica in another Availability Zone in the same Region\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-rds-rr-same-region.png)
Uma réplica de leitura do SQL Server não permite operações de gravação. No entanto, é possível promover a réplica de leitura para torná-la gravável. Depois de promovê-la, você não pode revertê-la para uma réplica de leitura. Ela se tornará uma instância de banco de dados única e autônoma que não tem nenhum relacionamento com sua instância de banco de dados primária original. Os dados na réplica de leitura promovida corresponderão aos dados na instância de banco de dados de origem até o ponto quando a solicitação foi feita para promovê-la. A versão do mecanismo de banco de dados SQL Server da instância de banco de dados de origem e todas as réplicas de leitura devem ser iguais.
Para uma replicação eficiente, recomendamos o seguinte:
+ Configure cada réplica de leitura com os mesmos recursos de computação e armazenamento da instância de banco de dados de origem.
+ Você deve habilitar backups automáticos na instância de banco de dados de origem, definindo o período de retenção de backup como um valor diferente de 0 (zero).
+ A instância de banco de dados de origem deve ser uma implantação Multi-AZ com Grupos de disponibilidade Always On.
Para obter suporte, edições e limitações da versão do SQL Server, consulte [Leia as limitações da réplica com o SQL Server na documentação](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.ReadReplicas.html#SQLServer.ReadReplicas.Limitations) do Amazon RDS.
Para obter mais informações sobre o uso de réplicas de leitura, consulte [Trabalho com réplicas de leitura](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) e [Trabalho com réplicas de leitura do SQL Server para Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.ReadReplicas.html) na documentação. AWS Para ter mais informações sobre a definição e preço da transferência de dados, consulte [Definição de preço do Amazon RDS](https://aws.amazon.com/rds/pricing/).
## Recuperação de desastres
Com o Amazon RDS para SQL Server, você pode criar uma estratégia confiável de recuperação de desastres (DR) entre regiões. Os principais motivos para criar uma solução de DR são a continuidade dos negócios e a conformidade:
+ Uma estratégia eficaz de DR ajuda você a manter seus sistemas em funcionamento com o mínimo ou nenhuma interrupção durante um evento catastrófico. Uma estratégia confiável e eficaz de DR entre regiões mantém sua empresa em operação mesmo que uma região inteira fique off-line.
+ Uma solução de DR entre regiões ajuda você a atender aos requisitos de auditoria e conformidade.
O objetivo de ponto de recuperação (RPO), o objetivo de tempo de recuperação (RTO) e o custo são três métricas principais a serem consideradas ao desenvolver sua estratégia de DR. Para outras opções para fornecer réplicas entre regiões, consulte [AWS Marketplace](https://aws.amazon.com/marketplace/). Para obter mais informações sobre essas abordagens, consulte [Recuperação de desastres entre regiões do Amazon RDS for SQL Server](https://aws.amazon.com/blogs/database/cross-region-disaster-recovery-of-amazon-rds-for-sql-server/) no blog AWS do banco de dados.
# Amazon RDS Custom for SQL Server
Se você não conseguir migrar para um serviço totalmente gerenciado, como o Amazon RDS, devido aos requisitos de personalização de aplicativos de terceiros, poderá migrar para o Amazon RDS Custom for SQL Server. Com o Amazon RDS Custom, você pode reter os direitos administrativos do banco de dados e seu sistema operacional subjacente para habilitar aplicativos dependentes.
## Quando escolher o Amazon RDS Custom for SQL Server
O Amazon RDS Custom para SQL Server é uma opção de migração quando:
+ Você tem aplicativos herdados, personalizados e em pacote que exigem acesso ao sistema operacional subjacente e ao ambiente de banco de dados.
+ Você precisa de acesso administrativo do usuário para atender aos requisitos de implantação de aplicativos baseados no fornecedor.
+ Você precisa acessar o sistema operacional subjacente para definir configurações, instalar patches e habilitar atributos nativos para atender aos requisitos da aplicação dependente.
+ Você deseja acessar e personalizar o ambiente de banco de dados (aplicando patches de banco de dados personalizados ou modificando pacotes de sistema operacional) para atender às suas necessidades de banco de dados e aplicativos.
## Como funciona
Para usar o Amazon RDS Custom para SQL Server, revise os [requisitos](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html#custom-reqs-limits.reqsMS) na documentação do Amazon RDS Custom para SQL Server. Você deve primeiro configurar seu ambiente para o Amazon RDS Custom for SQL Server, conforme explicado na [documentação do Amazon RDS.](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-setup-sqlserver.html) Depois que o ambiente estiver configurado, siga essas etapas, ilustradas no diagrama a seguir:
1. Crie uma instância de banco de dados do Amazon RDS Custom para SQL Server usando uma versão de mecanismo oferecida pelo Amazon RDS Custom.
O Amazon RDS Custom para SQL Server atualmente oferece suporte ao SQL Server 2019 e ao SQL Server 2022 no Windows 2019 com as [classes de instância de banco de dados compatíveis](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html#custom-reqs-limits.instancesMS) listadas na documentação. Para obter mais informações, consulte [Criar uma instância de banco de dados do RDS Custom para SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-creating-sqlserver.html#custom-creating-sqlserver.create).
1. Conecte seu aplicativo ao endpoint da instância de banco de dados do Amazon RDS Custom.
Para obter mais informações, consulte [Conectando-se à sua instância de banco de dados personalizada do RDS usando AWS Systems Manager](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-creating-sqlserver.html#custom-creating-sqlserver.ssm) e [Conectando-se à sua instância de banco de dados personalizada do RDS usando o RDP](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-creating-sqlserver.html#custom-creating-sqlserver.rdp).
1. (Opcional) Acessar o host para personalizar o software.
1. Monitore notificações e mensagens geradas pela automação do Amazon RDS Custom.
Para obter mais informações sobre o , consulte a Documentação do [Amazon RDS Custom](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-sqlserver.workflow.html).
![\[Fluxo de trabalho do Amazon RDS Custom for SQL Server\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/migration-sql-server/images/custom-rds-sql-server.png)
O Amazon RDS Custom é um serviço de banco de dados gerenciado que automatiza a configuração, a operação e a escalabilidade de bancos de dados na nuvem, ao mesmo tempo em que concede acesso ao sistema operacional subjacente e ao ambiente de banco de dados. No Amazon RDS Custom for SQL Server, você pode instalar softwares para executar aplicativos e atendentes personalizados. Como você tem acesso privilegiado ao host, pode modificar sistemas de arquivos para oferecer suporte a aplicações herdadas. Você pode aplicar patches de banco de dados personalizados ou modificar pacotes do SO nas suas instâncias de banco de dados do Amazon RDS Custom.
Se quiser personalizar sua instância, você pode pausar a automação personalizada do Amazon RDS Custom por até 24 horas e depois retomá-la quando o trabalho de personalização estiver concluído. Pausar a automação impede que a automação do Amazon RDS interfira diretamente com suas personalizações.
Quando você retoma a automação, o [perímetro de suporte](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-troubleshooting.html#custom-troubleshooting.support-perimeter) determina se a personalização do ambiente do banco de dados ou do sistema operacional interfere ou interrompe a automação personalizada do Amazon RDS Custom. O Amazon RDS Custom oferece suporte à personalização do ambiente de host e banco de dados, desde que suas alterações não coloquem a instância de banco de dados fora do perímetro de suporte. Por padrão, as verificações do perímetro de suporte são realizadas a cada 30 minutos e também ocorrem após eventos como exclusões de snapshots ou desinstalação do atendente personalizado do Amazon RDS Custom, que monitora a instância de banco de dados. O atendente personalizado do Amazon RDS Custom é um componente essencial para garantir a funcionalidade do Amazon RDS Custom. Se você desinstalar o atendente, o Amazon RDS Custom executará a verificação do perímetro de suporte após um minuto e moverá a instância de banco de dados para fora do perímetro de suporte.
Quando você configura uma instância de banco de dados do Amazon RDS Custom para o Microsoft SQL Server, a licença do software é incluída. Isso significa que você não precisará adquirir licenças do SQL Server em separado. Para obter mais informações sobre licenciamento, consulte a seção 10.5 em [termos de serviço da AWS](https://aws.amazon.com/service-terms/). Se você tiver uma conta ativa do AWS Premium Support, entre em contato com o AWS Premium Support for Amazon RDS Custom para problemas específicos do SQL Server.
O Amazon RDS Custom for SQL Server é suportado em uma seleção limitada de Regiões da AWS e com classes de instância de banco de dados limitadas. Para essas e outras limitações, consulte a página de [requisitos e limitações](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits-MS.html) na documentação do Amazon RDS Custom para SQL Server.
Se você tiver um banco de dados SQL Server on-premises, poderá seguir o processo descrito na [documentação do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-migrating.html) para migrá-lo para o Amazon RDS Custom for SQL Server usando utilitários de backup e restauração nativos.
Para obter mais informações, consulte os recursos a seguir:
+ [Novo — O Amazon RDS Custom para SQL Server está disponível ao público em geral](https://aws.amazon.com/blogs/aws/new-amazon-rds-custom-for-sql-server-is-generally-available/) (blog de AWS notícias)
+ [Configurar a replicação do SQL Server entre o Amazon RDS Custom for SQL Server e o Amazon RDS for SQL](https://aws.amazon.com/blogs/database/configure-sql-server-replication-between-amazon-rds-custom-for-sql-server-and-amazon-rds-for-sql-server/) Server AWS (blog do banco de dados)
+ [Automatize a migração local ou do Amazon EC2 SQL Server para o Amazon RDS para SQL Server usando o envio personalizado](https://aws.amazon.com/blogs/database/automate-on-premises-or-amazon-ec2-sql-server-to-amazon-rds-for-sql-server-migration-using-custom-log-shipping/) de registros (blog do banco de dados)AWS
+ [Configure a alta disponibilidade com grupos de disponibilidade sempre ativos no Amazon RDS Custom for SQL Server](https://aws.amazon.com/blogs/database/configure-high-availability-with-always-on-availability-groups-on-amazon-rds-custom-for-sql-server/) (blog do AWS banco de dados)
+ [Comece a usar o Amazon RDS Custom for SQL Server usando um CloudFormation modelo (Configuração de rede) (](https://aws.amazon.com/blogs/database/get-started-with-amazon-rds-custom-for-sql-server-using-an-aws-cloudformation-template-network-setup/)blog do AWS banco de dados)
+ [Migre cargas de trabalho locais do SQL Server para o Amazon RDS Custom for SQL Server usando grupos de disponibilidade distribuídos](https://aws.amazon.com/blogs/database/migrate-on-premises-sql-server-workloads-to-amazon-rds-custom-for-sql-server-using-distributed-availability-groups/) (blog do banco de dados)AWS
+ [Otimize seus custos do SQL Server usando traga sua própria mídia (BYOM) no Amazon RDS Custom for SQL Server](https://aws.amazon.com/blogs/database/optimize-your-sql-server-costs-by-using-bring-your-own-media-byom-on-amazon-rds-custom-for-sql-server/) (blog do AWS banco de dados)
# 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.
# VMware Nuvem ativada AWS para SQL Server
**Aviso**
Em 30 de abril de 2024, o VMware Cloud on não AWS é mais revendido por AWS ou por seus parceiros de canal. O serviço continuará disponível por meio da Broadcom. Recomendamos que você entre em contato com seu AWS representante para obter detalhes.
VMware O [Cloud on AWS](https://aws.amazon.com/vmware/) é uma oferta de nuvem integrada desenvolvida em conjunto por e. AWS VMware O SQL Server se integra facilmente ao VMware Cloud on. AWS Essa opção de migração permite que você aproveite seu investimento existente em virtualização.
Você pode acessar a VMware nuvem de hora AWS em hora, sob demanda ou em forma de assinatura. Ele inclui as mesmas VMware tecnologias básicas que você executa em seus data centers, incluindo vSphere Hypervisor (ESXi), Virtual SAN (vSAN) e a plataforma de virtualização de rede NSX, e foi projetado para fornecer uma experiência eficiente e perfeita para gerenciar seus bancos de dados do SQL Server. Você pode escalar o armazenamento, a computação e a memória de seus bancos de dados do SQL Server na VMware nuvem em AWS minutos.
VMware O Cloud on AWS é executado diretamente no hardware físico, mas aproveita os recursos de rede e hardware que foram projetados para oferecer suporte ao modelo de infraestrutura que AWS prioriza a segurança. Isso significa que a pilha de VMware virtualização é executada na AWS infraestrutura sem precisar usar a virtualização aninhada.
VMware Com AWS o Cloud on, é fácil configurar, escalar e operar suas cargas de trabalho de bancos de dados do SQL Server. AWS Ele fornece soluções de alta disponibilidade, integra-se ao Active Directory local e fornece acesso a AWS serviços como AWS Directory Service for Microsoft Active Directory AD Connector, Amazon Route 53 CloudWatch, Amazon e Amazon S3. Você pode armazenar seus backups no Amazon S3 e modernizar e simplificar seu processo de recuperação de desastres.
## Quando escolher o VMware Cloud on AWS
VMware O Cloud on AWS é uma opção para seu banco de dados SQL Server quando:
+ Seus bancos de dados do SQL Server já estão sendo executados em um data center on-premises em um ambiente virtualizado vSphere.
+ Você tem um grande número de bancos de dados e precisa de uma migração rápida (por exemplo, apenas algumas horas) para a nuvem por um dos seguintes motivos, sem exigir nenhum trabalho adicional da equipe de migração:
+ Extensão do data center. Você precisa de capacidade sob demanda para executar desktops virtualizados, publicar aplicativos ou fornecer um ambiente. development/testing
+ Recuperação de desastres Você deseja configurar um novo sistema de recuperação de desastres ou substituir seu sistema existente.
+ Migração para a nuvem Você quer migrar todo o seu data center para a nuvem ou atualizar sua infraestrutura.
Se o banco de dados do SQL Server exigir mais de 80 mil IOPS, você poderá usar o vSAN.
Para obter mais informações, consulte [In the Works — VMware Cloud AWS on](https://aws.amazon.com/blogs/aws/in-the-works-vmware-cloud-on-aws/) the AWS News blog e [Deploy Microsoft SQL Server on VMware Cloud AWS on Cloud](https://aws.amazon.com/solutionspace/solutions/sql-server-vmware-cloud-on-aws/) no AWS site.