Compartir por


Soluciones de replicación entre regiones para regiones no emparejadas

Algunos servicios de Azure admiten la replicación entre regiones para garantizar la continuidad empresarial y protegerse contra la pérdida de datos. Estos servicios usan otra región secundaria que usa replicación entre regiones. Las regiones primaria y secundaria juntas forman un par de regiones.

Sin embargo, hay algunas regiones de que no están emparejadas y, por tanto, requieren métodos alternativos para lograr la replicación geográfica.

En este documento se enumeran algunos de los servicios y las posibles soluciones que admiten métodos de replicación geográfica sin necesidad de regiones emparejadas.

Azure App Service

Para App Service, las copias de seguridad personalizadas se almacenan en una cuenta de almacenamiento seleccionada. Como resultado, hay una dependencia para la restauración entre regiones en GRS y regiones emparejadas. Para el tipo de copia de seguridad automática, no puede realizar copias de seguridad ni restaurar entre regiones. Como solución alternativa, puede implementar un mecanismo de copia de archivos personalizado para que el conjunto de datos guardado se copie manualmente en regiones no emparejadas y diferentes cuentas de almacenamiento.

Azure Backup

Para lograr la replicación geográfica en regiones no emparejadas:

  • Use Azure Site Recovery.  Azure Site Recovery es el servicio de recuperación ante desastres de Azure que proporciona continuidad empresarial y recuperación ante desastres mediante la replicación de cargas de trabajo desde la ubicación principal a la ubicación secundaria. La ubicación secundaria puede ser una región no emparejada si es compatible con Azure Site Recovery. Puede tener una retención de datos máxima de hasta 15 días con Azure Site Recovery.
  • Use Almacenamiento con redundancia de zona para replicar los datos en zonas de disponibilidad, lo que garantiza la residencia y resistencia de los datos en la misma región.

Azure Database for MySQL

Elija cualquier Regiones de Azure Database for MySQL disponibles para poner en marcha las réplicas de lectura.

Azure Database for PostgreSQL

Para la replicación geográfica en regiones no emparejadas con Azure Database for PostgreSQL, puede usar:

Servicio administrado con replicación geográfica: el servicio administrado de Azure PostgreSQL admite la replicación geográfica activo para crear una réplica secundaria legible continuamente del servidor principal. La réplica secundaria legible puede estar en la misma región de Azure que la principal o, más comúnmente, en otra región. Este tipo de réplica secundaria legible también se conoce como réplica geográfica.

También puede usar cualquiera de los dos métodos de migración de datos administrados por el cliente que se enumeran a continuación para replicar los datos en una región no emparejada.

Azure Data Factory

Para la replicación geográfica en regiones no emparejadas, Azure Data Factory (ADF) admite el aprovisionamiento de infraestructura como código de canalizaciones de ADF combinadas con control de código fuente para ADF.

Azure Event Grid

Para la replicación geográfica de temas de Event Grid en regiones no emparejadas, puede implementar conmutación por error del lado cliente.

Azure IoT Hub

Para la replicación geográfica en regiones no emparejadas, use el patrón de conserjería para el enrutamiento a una instancia secundaria de IoT Hub.

Azure Key Vault

Para las regiones de Azure que no emparejadas, así como las regiones Sur de Brasil y Oeste de EE. UU. 3, Azure Key Vault usa el almacenamiento con redundancia de zona (ZRS) para replicar los datos tres veces dentro de la región, en zonas de disponibilidad independientes. Para Azure Key Vault Premium, se usan dos de las tres zonas para replicar las claves del módulo de seguridad de hardware (HSM).

También puede usar la característica de copia de seguridad y restauración para replicar el contenido del almacén en otra región de su elección.

Azure Kubernetes Service (AKS)

Azure Backup puede proporcionar protección para clústeres de AKS, incluida una restauración entre regiones (CRR) característica que se encuentra actualmente en versión preliminar y solo admite Discos de Azure. Aunque la característica CRR se basa en réplicas de regiones emparejadas con GRS, se puede evitar cualquier dependencia de CRR si el clúster de AKS almacena datos solo en almacenamiento externo y evita el uso de soluciones "en clúster".

Registros de Azure Monitor

Las áreas de trabajo de Log Analytics en los registros de Azure Monitor no usan regiones emparejadas. Para garantizar la continuidad empresarial y protegerse contra la pérdida de datos, habilite la replicación del área de trabajo entre regiones.

Para más información, consulte Mejorar la resistencia mediante la replicación del área de trabajo de Log Analytics entre regiones

Azure SQL Database

Para la replicación geográfica en regiones no emparejadas con Azure SQL Database, puede usar:

  • Característica de grupo de conmutación por error que se replica en cualquier combinación de regiones de Azure sin ninguna dependencia de GRS de almacenamiento subyacente.

  • Característica de replicación geográfica activa crear una base de datos secundaria legible sincronizada continuamente para una base de datos principal. La base de datos secundaria legible puede estar en la misma región de Azure que la principal o, más comúnmente, en otra región. Este tipo de base de datos secundaria legible también se conoce como una secundaria geográfica o réplica geográfica.

Instancia administrada de Azure SQL

Para la replicación geográfica en regiones no emparejadas con Azure SQL Managed Instance, puede usar:

Azure Storage

Para lograr la replicación geográfica en regiones no emparejadas:

  • Para Azure Object Storage:

    Nota:

    No se admite la replicación de objetos para Azure Data Lake Storage.

  • Para Azure NetApp Files (ANF), puede replicar en un conjunto de pares no estándar además de pares de regiones de Azure. Consulte replicación entre regiones de Azure NetApp Files (ANF).

  • Para Azure Files:

    Importante

    Debe deshabilitar la nube por niveles para asegurarse de que todos los datos están presentes localmente y aprovisionar suficiente almacenamiento en la máquina virtual de Azure para contener todo el conjunto de datos. Para asegurarse de que los cambios se replican rápidamente en la región secundaria, solo se debe tener acceso a los archivos y modificarlos en el punto de conexión del servidor en lugar de en Azure.

Pasos siguientes