Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Amazon EC2 para SQL Server
Amazon EC2 admite una base de datos de SQL Server autoadministrada. Es decir, le proporciona un control total sobre la configuración de la infraestructura y el entorno de la base de datos. La ejecución de la base de datos en Amazon EC2 es muy similar a la ejecución de la base de datos en su propio servidor. Usted tiene el control total de la base de datos y del acceso a nivel del sistema operativo, por lo que puede utilizar las herramientas que desee para administrar el sistema operativo, el software de la base de datos, los parches, la replicación de datos, las copias de seguridad y la restauración. Esta opción de migración requiere que configure, administre y ajuste todos los componentes, incluidas las instancias EC2, los volúmenes de almacenamiento, la escalabilidad, las redes y la seguridad, según las mejores prácticas de arquitectura. AWS Usted es responsable de la replicación y recuperación de los datos en sus instancias de la misma región o de regiones diferentes AWS .
## Cuándo elegir Amazon EC2
Amazon EC2 es una buena opción de migración para su base de datos de SQL Server cuando:
+ Necesita tener el control total de la base de datos y el acceso a su sistema operativo subyacente, instalación de base de datos y configuración.
+ Desea administrar su base de datos, incluidas las copias de seguridad y la recuperación, aplicar parches al sistema operativo y la base de datos, ajustar los parámetros del sistema operativo y de la base de datos, administrar la seguridad y configurar la alta disponibilidad o la replicación.
+ Desea utilizar características y opciones que Amazon RDS no admite actualmente. Para obtener más información, consulte [Características no compatibles y características con compatibilidad limitada](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureNonSupport) en la documentación de Amazon RDS.
+ Necesita una versión específica de SQL Server que no sea compatible con Amazon RDS. Para obtener una lista actualizada de las versiones y ediciones compatibles, consulte [versiones de SQL Server en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.VersionSupport) en la documentación de Amazon RDS.
+ Las necesidades de tamaño y rendimiento de su base de datos superan las ofertas de Amazon RDS para SQL Server. Para obtener más información, consulte el [Almacenamiento de instancias de base de datos de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) en la documentación de Amazon RDS.
+ Desea evitar los parches de software automáticos que podrían no ser compatibles con sus aplicaciones.
+ Desea traer su propia licencia en lugar de utilizar el modelo con licencia incluida de Amazon RDS para SQL Server.
+ Desea lograr mayores IOPS y una capacidad de almacenamiento superior a los límites actuales. Para obtener más información, consulte el [Almacenamiento de instancias de base de datos de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) en la documentación de Amazon RDS.
Para obtener una lista de las características y versiones de SQL Server compatibles actualmente en Amazon EC2, consulte [Cómo elegir entre Amazon EC2 y Amazon RDS](comparison.md) más adelante en esta guía.
# Alta disponibilidad
Puede utilizar cualquier tecnología de replicación compatible con SQL Server con su base de datos de SQL Server en Amazon EC2 para lograr una alta disponibilidad, protección de datos y recuperación de desastres. Algunas de las soluciones más habituales son el envío de registros, la duplicación de la base de datos, los grupos de disponibilidad Always On y las instancias de clúster de conmutación por error Always On.
El siguiente diagrama muestra cómo puede usar SQL Server en Amazon EC2 en varias zonas de disponibilidad dentro de una sola AWS región. La base de datos principal es una base de datos de lectura y escritura y la base de datos secundaria está configurada con envío de registros, duplicación de la base de datos o grupos de disponibilidad Always On para una alta disponibilidad. Se transfieren todos los datos de transacciones de la base de datos principal y se pueden aplicar a la base de datos secundaria de forma asíncrona para el envío de registros y de forma asíncrona para los grupos de disponibilidad Always On y la duplicación.
![\[SQL Server on Amazon EC2 in a Multi-AZ configuration in one AWS Region\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-ec2.png)
# Envío de registros
El envío de registros le permite enviar automáticamente las copias de seguridad de registros de transacciones desde una instancia de base de datos principal a una o más bases de datos secundarias (también denominadas *en modo de espera activa*) en instancias de base de datos independientes. El envío de registros utiliza los trabajos del agente de SQL Server para automatizar el proceso de copia de seguridad, copia y aplicación de las copias de seguridad de registros de transacciones. Si bien el envío de registros suele considerarse una característica de recuperación de desastres, también puede proporcionar una alta disponibilidad al permitir la promoción de instancias de base de datos secundarias en caso de que se produzca un error en la instancia de base de datos principal. Si su RTO y su RPO son flexibles, o si sus bases de datos no se consideran muy esenciales, considere la posibilidad de utilizar el envío de registros para ofrecer una mejor disponibilidad a las bases de datos de SQL Server.
El envío de registros aumenta la disponibilidad de las bases de datos al proporcionar acceso a bases de datos secundarias para utilizarlas como copias de solo lectura de la base de datos principal, cuando sea necesario. Puede configurar un retraso (un tiempo de retardo mayor) durante el cual podrá recuperar los datos modificados accidentalmente en la base de datos principal antes de que estos cambios se envíen a la base de datos secundaria.
Se recomienda ejecutar las instancias de base de datos principal y secundaria en zonas de disponibilidad independientes y desplegar una instancia de supervisión para realizar un seguimiento de todos los detalles del envío de registros. Los eventos de copia de seguridad, copia, restauración y error de un grupo de envío de registros están disponibles en la instancia de supervisión. Una configuración de envío de registros no realiza automáticamente la conmutación por error del servidor principal al servidor secundario. Sin embargo, cualquiera de las bases de datos secundarias se puede poner en línea manualmente si la base de datos principal deja de estar disponible.
El envío de registros se suele utilizar como una solución de recuperación de desastres, pero también se puede utilizar como una solución de alta disponibilidad, según los requisitos de la aplicación. Utilice el envío de registros cuando:
+ Tenga requisitos de RTO y RPO flexibles. El envío de registros proporcione un RPO de minutos y un RTO de minutos a horas.
+ No necesite una conmutación por error automática a la base de datos secundaria.
+ Desee leer datos de la base de datos secundaria, pero no necesite legibilidad durante una operación de restauración.
Para obtener más información sobre el envío de registros, consulte la [documentación de Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/log-shipping/about-log-shipping-sql-server).
# Duplicación de bases de datos
La duplicación de la base de datos toma una base de datos que se encuentra en una instancia EC2 y proporciona una copia completa o casi completa de solo lectura (duplicado) de la misma en una instancia de base de datos independiente. Amazon RDS utiliza la duplicación de bases de datos para proporcionar compatibilidad con multi-AZ a Amazon RDS para SQL Server. Esta característica aumenta la disponibilidad y la protección de las bases de datos y proporciona un mecanismo para mantener las bases de datos disponibles durante las actualizaciones.
**nota**
Según la [documentación de Microsoft](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server), la duplicación de bases de datos se eliminará en una futura versión de SQL Server. En su lugar, debería planear usar los grupos de disponibilidad Always On.
En la duplicación de bases de datos, SQL Server puede desempeñar una de estas tres funciones:
+ El servidor principal, que aloja la read/write versión principal de la base de datos.
+ Servidor duplicado, que aloja una copia de la base de datos principal.
+ Servidor de testigo opcional. Este servidor solo está disponible en el modo de alta seguridad. Supervisa el estado del duplicado de la base de datos y automatiza la conmutación por error de la base de datos principal a la base de datos duplicada.
Se establece una sesión de duplicación entre el servidor principal y el servidor duplicado. Durante la duplicación, todos los cambios en la base de datos que se realizan en la base de datos principal también se realizan en la base de datos duplicada. La duplicación de bases de datos puede ser una operación síncrona o asíncrona. Esto se determina mediante dos modos de funcionamiento de duplicación: el modo de alta seguridad y el modo de alto rendimiento.
+ **Modo de alta seguridad:** este modo utiliza operaciones síncronas. En este modo, la sesión de duplicación de la base de datos sincroniza las operaciones de inserción, actualización y eliminación de la base de datos principal con la base de datos duplicada lo más rápido posible. En cuanto se sincroniza la base de datos, la transacción se confirma en la base de datos principal y en la base de datos duplicada. Se recomienda utilizar este modo de funcionamiento cuando las bases de datos duplicadas estén en la misma zona de disponibilidad o en zonas diferentes, pero alojadas en la misma región de AWS .
+ **Modo de alto rendimiento:** este modo utiliza operaciones asíncronas. En este modo, la sesión de duplicación de la base de datos sincroniza las operaciones de inserción, actualización y eliminación de la base de datos principal con la base de datos duplicada, pero puede haber un retraso entre el momento en que la base de datos principal confirma las transacciones y el momento en que la base de datos duplicada confirma las transacciones. Se recomienda utilizar este modo cuando las bases de datos reflejadas estén en AWS regiones diferentes.
Utilice la duplicación de bases de datos cuando:
+ Tenga requisitos estrictos de RTO y RPO y no pueda haber demoras entre las bases de datos principal y secundaria. La duplicación de bases de datos proporciona un RPO de cero segundos (con confirmación síncrona) y un RTO de segundos a minutos.
+ No tenga un requisito de leer datos de la base de datos secundaria.
+ Desee realizar una conmutación por error automática cuando tenga un servidor de testigo configurado en modo de sincronización.
+ No pueda usar los grupos de disponibilidad Always On, que es la opción preferida.
Limitaciones:
+ Solo se admite la one-to-one conmutación por error. No puede hacer que varios destinos de base de datos se sincronicen con la base de datos principal.
Para obtener más información sobre la replicación, consulte la [documentación de Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server).
# Grupos de disponibilidad AlwaysOn
Los grupos de disponibilidad Always On de SQL Server proporcionan soluciones de alta disponibilidad y recuperación de desastres para las bases de datos de SQL Server. Un grupo de disponibilidad consta de un conjunto de bases de datos de usuarios que realizan la conmutación por error entre sí. Incluye un único conjunto de read/write bases de datos principales y varios conjuntos (de uno a ocho) conjuntos de bases de datos secundarias relacionadas. Puede hacer que las bases de datos secundarias estén disponibles en el nivel de aplicación como copias de solo lectura de las bases de datos principales (solo en la edición SQL Server Enterprise), a fin de proporcionar una arquitectura de escalado ascendente para las cargas de trabajo de lectura. También puede utilizar las bases de datos secundarias para operaciones de copia de seguridad.
Los grupos de disponibilidad Always On de SQL Server admiten los modos de confirmación sincrónico y asincrónico. En el modo sincrónico, la réplica principal confirma las transacciones de la base de datos después de confirmar o escribir los cambios en el registro de la réplica secundaria. Con este modo, puede realizar una conmutación por error manual planificada y una conmutación por error automática si las réplicas están sincronizadas. Puede usar el modo de confirmación sincrónica entre instancias de SQL Server dentro del mismo entorno (por ejemplo, si todas las instancias son locales o todas las instancias están dentro). AWS
En el modo de confirmación asincrónico, la réplica principal confirma las transacciones de la base de datos sin esperar a la réplica secundaria. Puede usar el modo de confirmación asíncrono entre instancias de SQL Server que se encuentren en entornos diferentes (por ejemplo, si tiene instancias locales y locales). AWS
Puede usar los grupos de disponibilidad Always On para una alta disponibilidad o una recuperación de desastres. Utilice este método cuando:
+ Tenga requisitos de RTO y RPO estrictos. Los grupos de disponibilidad Always On proporcionan un RPO de segundos y un RTO de segundos a minutos.
+ Desee administrar un grupo de bases de datos y realizar una conmutación por error en él. Los grupos de disponibilidad Always On admiten de 0 a 4 réplicas secundarias en el modo de confirmación síncrona para SQL Server 2019.
+ Desee utilizar la conmutación por error automática en el modo de confirmación síncrona y no necesite un servidor de testigo.
+ Desee leer datos de la base de datos secundaria.
+ Desea sincronizar múltiples destinos de base de datos con la base de datos principal.
A partir de SQL Server 2016 SP1, la edición SQL Server Standard proporciona una alta disponibilidad básica para una base de datos secundaria única e ilegible y un agente de escucha por grupo de disponibilidad. También admite un máximo de dos nodos por grupo de disponibilidad.
# Instancias en clúster de conmutación por error de Always On
Las instancias de clúster de conmutación por error Always On de SQL Server (FCIs) utilizan el clúster de conmutación por error de Windows Server (WSFC) para proporcionar una alta disponibilidad a nivel de instancia de servidor. Una FCI es una instancia única de SQL Server que se instala en los nodos de WSFC para ofrecer una alta disponibilidad durante toda la instalación de SQL Server. Si el nodo subyacente sufre errores de hardware, sistema operativo, aplicación o servicio, todo el contenido de la instancia de SQL Server se mueve a otro nodo de WSFC. Esto incluye las bases de datos del sistema, los inicios de sesión de SQL Server, los trabajos del agente de SQL Server y los certificados.
Por lo general, se prefiere una FCI a un grupo de disponibilidad Always On cuando:
+ Utiliza la edición SQL Server Standard en lugar de Enterprise Edition.
+ Tiene una gran número de bases de datos pequeñas por instancia.
+ Modifica constantemente los objetos a nivel de instancia, como los trabajos del agente de SQL Server, los inicios de sesión, etc.
Existen cuatro opciones de implementación en: FCIs AWS
+ Amazon EBS Multi-Attach con reservas persistentes
+ Servidor FSx de archivos Amazon para Windows
+ Amazon FSx para NetApp ONTAP
+ Soluciones de socios AWS
## Uso de Amazon EBS Multi-Attach con reservas persistentes
[Amazon EBS Multi-Attach with NVMe reserves](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-reservations.html) admite la creación de `io2` volúmenes de SQL Server con FCIs Amazon EBS como almacenamiento compartido en los clústeres de conmutación por error de Windows Server. Esta característica simplifica el proceso de configuración del clúster de conmutación por error al permitirle crear un clúster de conmutación por error mediante volúmenes de Amazon EBS `io2`. Estos volúmenes se pueden vincular solo a las instancias que se encuentren en la misma zona de disponibilidad. Para implementar clústeres de conmutación por error de Windows Server mediante `io2` volúmenes de Amazon EBS, debe utilizar los controladores más recientes AWS NVMe .
Los volúmenes de Amazon EBS y los volúmenes de almacenes de instancias se exponen como dispositivos de NVMe bloques en las instancias [basadas en Nitro](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances). Debe tener el [AWS NVMe controlador](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html) instalado con la [función de reserva persistente SCSI](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html#configure-scsi-persistent-reservations) configurada cuando utilice `io2` volúmenes de Amazon EBS para formar WSFC y SQL Server. FCIs
Para obtener más información sobre esta función, consulte la entrada del AWS blog [Cómo implementar un clúster de conmutación por error de SQL Server con Amazon EBS Multi-Attach en](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-deploy-a-sql-server-failover-cluster-with-amazon-ebs-multi-attach-on-windows-server/) Windows Server.
## Uso del servidor de archivos de Amazon FSx para Windows
[Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) proporciona un almacenamiento de archivos compartido totalmente gestionado. Replica automáticamente el almacenamiento de forma síncrona en dos zonas de disponibilidad para ofrecer una alta disponibilidad. El uso de FSx for Windows File Server para el almacenamiento de archivos simplifica y optimiza las implementaciones de alta disponibilidad de SQL Server en Amazon EC2.
Con Microsoft SQL Server, la alta disponibilidad normalmente se implementa en varios nodos de bases de datos de WSFC, y cada nodo tiene acceso al almacenamiento de los archivos compartido. Puede utilizar el FSx servidor de archivos de Windows como almacenamiento compartido para las implementaciones de alta disponibilidad de SQL Server de dos maneras: como almacenamiento para archivos de datos activos y como testigo del uso compartido de archivos en pequeñas y medianas empresas.
Para obtener información sobre cómo puede reducir la complejidad y el coste de ejecutar las implementaciones FCI de SQL Server mediante FSx el uso de Windows File Server, consulte la entrada del blog [Simplifique las implementaciones de alta disponibilidad de Microsoft SQL Server con Amazon FSx for Windows](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) File Server. La entrada del blog también proporciona step-by-step instrucciones para implementar SQL Server FCIs mediante un sistema de archivos Amazon FSx Multi-AZ como solución de almacenamiento compartido. Para obtener más información, consulte la documentación de [Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html).
## Uso de Amazon FSx para NetApp ONTAP
Amazon FSx for NetApp ONTAP es un servicio totalmente gestionado que proporciona un almacenamiento de archivos altamente fiable, escalable, de alto rendimiento y rico en funciones que se basa en el NetApp sistema de archivos ONTAP. FSx for ONTAP combina las características, el rendimiento, las capacidades y las operaciones de API conocidas de los sistemas de NetApp archivos con la agilidad, la escalabilidad y la sencillez de un servicio totalmente gestionado. AWS
FSx for ONTAP proporciona acceso multiprotocolo a los datos a través de los protocolos NFS, SMB e iSCSI para sistemas Windows y Linux. Puede crear una arquitectura FCI de SQL Server Always On de alta disponibilidad, tal y como se explica en detalle en la entrada del 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 para ONTAP también puede proporcionar una forma rápida de conmutar por error su entorno de SQL Server a otro Región de AWS para cumplir con los requisitos del objetivo de tiempo de recuperación (RTO) y del objetivo de punto de recuperación (RPO). Para obtener más información, consulte la entrada del blog [Implementación de alta disponibilidad y recuperación ante desastres para una instancia de clúster de conmutación por error siempre activa de 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/) mediante ONTAP. FSx
También se puede utilizar AWS Launch Wizard para implementar soluciones de SQL Server en ellas AWS, ya que es compatible con grupos de disponibilidad Always On y despliegues de un solo nodo. Launch Wizard admite el despliegue de SQL Server Always on FCI en Amazon EC2 FSx con ONTAP como almacenamiento compartido. Este servicio le permite ahorrar tiempo y esfuerzo, ya que sustituye un complejo proceso de implementación manual por un asistente guiado y basado en una consola que acelera la migración de las cargas de trabajo de SQL Server en las instalaciones que dependen del almacenamiento compartido. Para obtener más información sobre cómo Launch Wizard puede ayudarle a aprovisionar y configurar SQL Server FCIs en cuestión de horas, consulte la entrada del blog [Simplifique las implementaciones de SQL Server Always On con AWS Launch Wizard Amazon FSx](https://aws.amazon.com/blogs/storage/simplify-sql-server-always-on-deployments-with-the-aws-launch-wizard-and-amazon-fsx/). Launch Wizard también admite la implementación de SQL Server Always On FCIs mediante [Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/) como solución de almacenamiento compartido.
## Uso de soluciones de AWS socios
+ [SIOS DataKeeper](https://us.sios.com/) proporciona un soporte de conmutación por error de clústeres de alta disponibilidad en todas las zonas Regiones de AWS de disponibilidad. SIOS DataKeeper está disponible en. [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 la conmutación por error totalmente automática de los grupos de disponibilidad de SQL Server en Kubernetes y la conmutación por error unificada de instancias para Windows y Linux. D2HI está disponible en [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=4e97d4b7-3366-42fd-8be8-732d38c9e24b).
# FSx para Windows File Server
FSx para Windows File Server proporciona un almacenamiento de archivos totalmente gestionado, altamente fiable y escalable al que se puede acceder mediante el protocolo Server Message Block (SMB). Se basa en Windows Server y ofrece una amplia gama de características administrativas, como cuotas de usuarios, restauración de archivos de usuarios finales e integración con Microsoft Active Directory (AD). Ofrece opciones de implementación single-AZ y multi-AZ, copias de seguridad completamente administradas y cifrado de datos en reposo y en tránsito. Puede optimizar el costo y el rendimiento de sus cargas de trabajo con opciones de almacenamiento en unidades de estado sólido (SSD) y unidades de disco duro (HDD), y puede escalar el almacenamiento y cambiar el rendimiento de su sistema de archivos en cualquier momento. Se puede acceder al almacenamiento de FSx archivos de Amazon desde instancias informáticas de Windows y Linux que se ejecutan en AWS las instalaciones y de forma local.
Amazon FSx facilita la implementación del almacenamiento compartido de Windows para las implementaciones de SQL Server de alta disponibilidad mediante su compatibilidad con los recursos compartidos de archivos de disponibilidad continua (CA) y los sistemas de archivos más pequeños. Esta opción es adecuada para los siguientes casos de uso:
+ Como almacenamiento compartido utilizado por los nodos de SQL Server en una instancia de WSFC.
+ Como testigo de archivos compartidos de SMB que se puede utilizar con cualquier clúster de SQL Server con WSFC.
Amazon FSx ofrece un rendimiento rápido con un rendimiento básico de hasta 2 GB/second por sistema de archivos, cientos de miles de IOPS y latencias consistentes de menos de un milisegundo.
Para proporcionar el rendimiento adecuado a sus instancias de SQL, puede elegir un nivel de rendimiento que sea independiente del tamaño de su sistema de archivos. Los niveles más altos de capacidad de rendimiento también vienen acompañados de niveles más altos de IOPS que el servidor de archivos puede ofrecer a las instancias de SQL Server que acceden a él.
La capacidad de almacenamiento determina no solo la cantidad de datos que puede almacenar, sino también la cantidad de IOPS que puede realizar en el almacenamiento. Cada gigabyte de almacenamiento proporciona 3 IOPS. Puede aprovisionar cada sistema de archivos para que tenga un tamaño de hasta 64 TB.
Para obtener información sobre la configuración y el uso de Amazon FSx para reducir la complejidad y los costes de las implementaciones de alta disponibilidad de SQL Server, consulte [Simplifique las implementaciones de alta disponibilidad de Microsoft SQL Server con FSx Windows File Server](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) en el blog AWS Storage. Para obtener más información sobre cómo crear un nuevo recurso compartido de CA, consulte la documentación del [servidor FSx de archivos de Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/managing-file-shares.html#create-ca-share).
# Recuperación ante desastres
Muchas organizaciones implementan una alta disponibilidad para sus bases de datos de SQL Server, pero eso no es suficiente para las organizaciones que requieren una verdadera resiliencia de TI. Le recomendamos que implemente una solución de recuperación de desastres para evitar la pérdida de datos y el tiempo de inactividad de las bases de datos esenciales. La adopción de una arquitectura de recuperación de desastres de varias regiones para sus implementaciones de SQL Server le ayudará a:
+ Lograr la continuidad del negocio
+ Mejorar la latencia de su base de clientes distribuidos geográficamente
+ Cumplir sus requisitos reglamentarios y de auditoría
Las opciones de recuperación ante desastres incluyen el [envío de registros](ec2-log-shipping.md), [los grupos de disponibilidad de Always On](ec2-always-on.md), las [instantáneas de Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html) que se almacenan en Amazon S3 y se replican en todas AWS las regiones, las [instancias de clúster de conmutación por error de Always On (FCIs)](ec2-fci.md) combinadas con los grupos de disponibilidad de Always On y los grupos de disponibilidad distribuidos.
## Grupos de disponibilidad distribuida
Una arquitectura con grupos de disponibilidad distribuidos es un enfoque óptimo para la implementación de SQL Server en varias regiones. Un grupo de disponibilidad distribuida es un tipo especial de grupo de disponibilidad que abarca dos grupos de disponibilidad independientes. Puede considerarlo como un grupo de disponibilidad de grupos de disponibilidad. Los grupos de disponibilidad subyacentes se configuran en dos clústeres WSFC distintos.
Los grupos de disponibilidad distribuidos están acoplados flexiblemente, lo que significa que no requieren un único clúster de WSFC y que son mantenidos por SQL Server. Como los clústeres de WSFC se mantienen de forma individual y las transmisiones son principalmente asincrónicas entre dos grupos de disponibilidad, resulta más fácil configurar la recuperación de desastres en otro sitio. Las réplicas principales de cada grupo de disponibilidad sincronizan sus propias réplicas secundarias.
Por el momento, los grupos de disponibilidad distribuidos solo admiten la conmutación por error manual. Para garantizar que no se pierdan datos, detenga todas las transacciones en las bases de datos principales globales (es decir, en las bases de datos del grupo de disponibilidad principal). A continuación, configure el grupo de disponibilidad distribuido para que se confirme de forma sincrónica.