Compartir a través de

Solución de problemas de replicación en recuperación ante desastres de VM de Azure

En este artículo se describen problemas comunes en Azure Site Recovery cuando se replican y recuperan máquinas virtuales (VM) de Azure de una región a otra. También se explica cómo solucionar los problemas habituales. Para más información sobre las configuraciones admitidas, consulte la matriz de compatibilidad para la replicación de máquinas virtuales de Azure.

Azure Site Recovery replica los datos de manera coherente de la región de origen a la región de recuperación ante desastres. También crea un punto de recuperación coherente con los bloqueos cada 5 minutos. Si Site Recovery no se puede crear puntos de recuperación durante 60 minutos, le avisa con esta información:

Error message: "No crash consistent recovery point available for the VM in the last 60 minutes."

Error ID: 153007

En las secciones siguientes se describen las causas y las soluciones.

Velocidad de cambio elevada en los datos de la máquina virtual de origen

Azure Site Recovery crea un evento si la frecuencia de cambio de datos en la máquina virtual de origen supera los límites admitidos. Para comprobar si el problema se debe una elevada renovación, vaya a Elementos replicados>Máquina virtual>Events -last 72 hours (Eventos: últimas 72 horas). Debería ver el evento Frecuencia de cambio de datos superior a los límites admitidos:

Página de Azure Site Recovery que muestra una frecuencia de cambio de datos que es demasiado alta.

Si selecciona el evento, debería ver la información exacta del disco:

Límites de Azure Site Recovery

En la tabla siguiente se proporcionan los límites de Azure Site Recovery. Estos límites se basan en nuestras pruebas, pero no pueden cubrir todas las combinaciones de E/S posibles de la aplicación. Los resultados reales pueden variar en función de la combinación de E/S de la aplicación.

Hay dos límites que se deben tener en cuenta: la frecuencia de modificación de datos por disco y la frecuencia de modificación de datos por máquina virtual. Revise los límites de renovación aquí.

Solución

Azure Site Recovery tiene límites en la frecuencia de cambio de datos según el tipo de disco. Para ver si este problema es periódico o temporal, busque la frecuencia de cambio en la máquina virtual afectada. Vaya a la máquina virtual de origen. busque las métricas en Supervisión y agregue las métricas como se muestra en esta captura de pantalla:

Página que muestra el proceso de tres pasos para buscar la frecuencia de cambio de datos.

  1. Seleccione Agregar métrica y agregue Bytes de escritura de discos del SO/s y Bytes de escritura de discos de datos/s.
  2. Supervise el aumento como se muestra en la captura de pantalla.
  3. Vea el total de todas las operaciones de escritura que se producen en el disco del sistema operativo y en todos los discos de datos. Estas métricas podrían no proporcionar información en el nivel de disco, pero indican el patrón de la actividad de datos.

Un pico en la frecuencia de cambio de los datos puede proceder de una ráfaga de datos ocasional. Si la frecuencia de cambio de datos supera los 10 MB/s (para Premium) o 2 MB/s (para Estándar) y desciende, la replicación mantendrá el ritmo. Sin embargo, si la renovación supera con creces y de manera constante el límite admitido, considere una de las siguientes opciones:

  • Excluya el disco que causa una alta tasa de cambio de datos: Primero, deshabilite la replicación. A continuación, puede excluir el disco mediante el uso de PowerShell.

  • Cambie el tamaño del disco de réplica. Esta opción solo es útil si la renovación de datos del disco es inferior a 20 MB/s por disco o menos de 50 MB/s por disco para alta renovación. Por ejemplo, suponiendo que no haya optado por una alta compatibilidad con la renovación y tenga una máquina virtual con disco de 128 GiB y una renovación de datos entre 8 MB/s y 10 MB/s. Ahora, el tamaño del disco de 128 GiB tiene un límite de renovación de 8 MB/s, puede aumentar el tamaño del disco a 512 GiB para admitir una mayor renovación. Esta solución solo es posible para las máquinas que usan Discos administrados Premium. Siga estos pasos:

    1. Vaya a Discos de la máquina replicada afectada y copie el nombre del disco de réplica.
    2. Vaya a esta réplica del disco administrado.
    3. Es posible que vea un mensaje emergente en Información general que indica que se ha generado una dirección URL de SAS. Seleccione este mensaje emergente y cancele la exportación. Omita este paso si no aparece el mensaje emergente.
    4. En cuanto se revoque la dirección URL de SAS, vaya a la opción de Size + Performance (Tamaño + rendimiento) del disco administrado. Aumente el tamaño para que Site Recovery admita la frecuencia de renovación observada en el disco de origen.

Importante

El límite de renovación admitido por Azure Site Recovery depende del tamaño de disco del disco SSD premium de réplica. Este límite sigue siendo el mismo aunque cambie el nivel de rendimiento del disco de réplica. Por ejemplo, si tiene un disco de réplica SSD prémium de tamaño de disco 128 GiB creado, su nivel de rendimiento base es P10. Si actualiza su nivel de rendimiento a P50 sin cambiar el tamaño del disco, el límite de renovación no cambiará.

Consideraciones de cambio de nivel o SKU de disco

Cada vez que cambie el nivel de disco o la SKU, el proveedor de recursos de disco crea todas las instantáneas (marcadores) correspondientes al disco. Por lo tanto, puede tener puntos de recuperación en los que algunas de las instantáneas subyacentes no existen al final del proveedor de recursos de disco.

Una vez que desencadene una conmutación por error con un punto de recuperación creado antes del cambio de nivel o SKU, la conmutación por error producirá un error de BookmarkNotFound. Dado que la eliminación de puntos de recuperación es un trabajo programado, es posible que vea estos puntos de recuperación en el portal aunque con el tiempo que se elimina.

Recomendación: espere un punto de recuperación creado con una fecha y hora después del cambio realizado en el disco.

Problemas de conectividad de red

Latencia de red en la cuenta de almacenamiento en caché

Site Recovery envía los datos replicados a la cuenta de almacenamiento en caché. Es posible que experimente latencia de red si la carga de los datos de una máquina virtual a la cuenta de almacenamiento en caché es inferior a 4 MB en 3 segundos.

Para comprobar si hay un problema relacionado con la latencia, use AzCopy. Puede usar esta utilidad de línea de comandos para cargar datos desde la máquina virtual a la cuenta de almacenamiento en caché. Si la latencia es alta, compruebe si está utilizando alguna aplicación virtual de red (NVA) para controlar el tráfico que sale de las máquinas virtuales. Es posible que se genere un cuello de botella si todo el tráfico de replicación pasa por la aplicación virtual de red.

Se recomienda crear un punto de conexión de servicio de red en la red virtual de "Storage" para que el tráfico de replicación no se dirija a la NVA. Para obtener más información, consulte Configuración de la aplicación virtual de red.

Conectividad de red

Para que la replicación de Site Recovery funcione, es necesario que la máquina virtual proporcione conectividad saliente a direcciones URL o intervalos IP específicos. Puede que la máquina virtual esté detrás de un firewall o que use reglas de grupo de seguridad de red (NSG) para controlar la conectividad saliente. Si es así, puede experimentar problemas. Consulte Conectividad de salida para las direcciones URL para comprobar que todas las direcciones URL están conectadas.

Id. del error: 153006. No hay ningún punto de recuperación coherente con la aplicación disponible para la máquina virtual en los "X" últimos minutos

A continuación se muestran algunos de los problemas más comunes.

Incidencia conocida en SQL Server 2008/2008 R2

Formas de corrección: existe una incidencia conocida en SQL Server 2008/2008 R2. Consulte el artículo Copia de seguridad de ASR Agent u otros VSS no componente produce un error en un servidor que aloja SQL Server 2008 R2.

Se producen errores en los trabajos de Azure Site Recovery en los servidores que alojan cualquier versión de las instancias de SQL Server con bases de datos AUTO_CLOSE

Formas de corrección: consulte el artículo Las copias de seguridad de VSS que no son componentes, como los trabajos de Azure Site Recovery, producen errores en los servidores que hospedan instancias de SQL Server con bases de datos AUTO_CLOSE.

Incidencia conocida en SQL Server 2016 y 2017

Cómo solucionar: Actualización acumulativa 16 para SQL Server 2017.

Está usando la configuración de Espacios de almacenamiento directo de Azure

Formas de corrección: Azure Site Recovery no puede crear un punto de recuperación coherente con la aplicación para la configuración de Espacios de almacenamiento directo. Configure la directiva de replicación.

La coherencia de aplicaciones no está habilitada en servidores Linux

Formas de corrección: Azure Site Recovery para el sistema operativo Linux admite scripts personalizados de aplicaciones para la coherencia de aplicaciones. El agente de movilidad de Azure Site Recovery usará el script personalizado con opciones previas y posteriores para la coherencia de aplicaciones. Aquí se indican los pasos necesarios para habilitarlo.

Para seguir solucionando el problema, compruebe los archivos en la máquina de origen para obtener el código de error exacto:

C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\Application Data\ApplicationPolicyLogs\vacp.log

Para encontrar los errores, abra el archivo vacp.log en un editor de texto y busque la cadena vacpError.

Ex: vacpError:220#Following disks are in FilteringStopped state [\\.\PHYSICALDRIVE1=5, ]#220|^|224#FAILED: CheckWriterStatus().#2147754994|^|226#FAILED to revoke tags.FAILED: CheckWriterStatus().#2147754994|^|

En el ejemplo anterior, 2147754994 es el código de error que le informa sobre el error después de esta frase.

VSS Writer no está instalado - Error 2147221164

Formas de corrección: para generar la etiqueta de coherencia de la aplicación, Azure Site Recovery usa el Servicio de instantáneas de volumen (VSS). Site Recovery instala un proveedor de VSS para su funcionamiento y para realizar instantáneas de la coherencia de las aplicaciones. Azure Site Recovery instala este proveedor VSS como servicio. Si el proveedor de VSS no está instalado, se produce un error en la creación de instantáneas de la coherencia de aplicaciones. Aparece el identificador de error 0x80040154 Clase no registrada. Consulte el artículo para solucionar problemas con la instalación de VSS Writer.

VSS Writer está deshabilitado - Error 2147943458

Formas de corrección: para generar la etiqueta de coherencia de la aplicación, Azure Site Recovery usa VSS. Site Recovery instala un proveedor de VSS para su funcionamiento y para realizar instantáneas de la coherencia de las aplicaciones. Este proveedor de VSS se instala como un servicio. Si el proveedor de VSS no está habilitado, se produce un error en la creación de instantáneas de la coherencia de aplicaciones. Muestra el error el servicio especificado está deshabilitado y no se puede iniciar (0x80070422).

Si VSS está deshabilitado:

  • Compruebe que el tipo de inicio del servicio de proveedor de VSS está establecido en Automático.
  • Reinicie los servicios siguientes:
    • Servicio VSS.
    • Proveedor VSS de Azure Site Recovery.
    • Servicio VDS.

NOT_REGISTERED del proveedor de VSS: error 2147754756

Formas de corrección: para generar la etiqueta de coherencia de la aplicación, Azure Site Recovery usa VSS. Compruebe si el servicio de proveedor de VSS de Azure Site Recovery está instalado.

Use los comandos siguientes para volver a instalar el proveedor de VSS:

  1. Desinstale el proveedor existente:

    "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Uninstall.cmd"

  2. Vuelva a instalar el proveedor de VSS:

    "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd"

Compruebe que el tipo de inicio del servicio de proveedor de VSS está establecido en Automático.

Reinicie los servicios siguientes:

  • Servicio VSS.
  • Proveedor VSS de Azure Site Recovery.
  • Servicio VDS.

Actualizar TenantId y ClientId manualmente en la máquina de origen

Corrección: para corregir el error de ausencia de latido de Mobility Service debido a inquilino vencido, siga estos pasos:

  1. Ejecute la API de elementos protegidos GET y recupere los valores de mobilityAgentTenantIdToUpdate y mobilityAgentClientIdToUpdate de la salida.

    GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{resourceName}/replicationFabrics/{fabricName}/replicationProtectionContainers/{protectionContainerName}/replicationProtectedItems/{replicatedProtectedItemName}?api-version=2025-01-01

  2. Abra el archivo RCMInfo.conf en la máquina de origen. La ubicación del archivo es la siguiente:

  • Windows: C:\ProgramData\Microsoft Azure Site Recovery\Config\RCMInfo.conf
  • Linux: /usr/local/InMage/config/RCMInfo.conf

  1. Actualice los valores de AADTenantId, AADClientId, y el tenantid de AADAudienceUri con los nuevos detalles del inquilino obtenidos en el paso 1 y guarde el archivo con el siguiente formato:

    AADTenantId=<mobilityAgentTenantIdToUpdate>
AADClientId=<mobilityAgentClientIdToUpdate>
AADAudienceUri=api://<mobilityAgentTenantIdToUpdate>/RecoveryServiceContainer/eastus2euap/1394977864085472368/3134366

  2. Reinicie los servicios siguientes:

    • Windows: "InMage Scout VX Agent - Sentinel/Outpost", "InMage Scout Application Service"
    • Linux: vxagent, appservice

Pasos siguientes

Replicación de máquinas virtuales de Azure en otra región de Azure.