Solución de problemas de replicación de máquinas virtuales de VMware y de servidores físicos

En este artículo se describen algunos problemas comunes y errores específicos que pueden surgir al replicar máquinas virtuales de VMware locales y servidores físicos en Azure mediante Site Recovery.

Paso 1: Supervisión del estado de los servidores de procesos

Site Recovery usa el servidor de procesos para recibir y optimizar los datos replicados y enviarlos a Azure.

Le recomendamos que supervise el estado de los servidores de procesos en el portal para asegurarse de que están conectados y funcionan correctamente, y de que hay una replicación en curso de las máquinas de origen asociadas al servidor de procesos.

  • Más información sobre cómo supervisar servidores de proceso
  • [Revise los procedimientos recomendados]. (vmware-physical-azure-troubleshoot-process-server.md#best-practices-for-process-server-deployment)
  • Solución de problemas de estado de los servidores de procesos

Paso 2: Solucionar problemas de conectividad y replicación

Los errores de replicación iniciales y continuados se deben a menudo a problemas de conectividad entre el servidor de origen y el servidor de procesos, o entre el servidor de procesos y Azure.

Para resolver estos problemas, solucione problemas de conectividad y replicación.

Paso 3: Solucionar problemas de máquinas de origen que no están disponibles para la replicación

Cuando intenta seleccionar la máquina de origen para habilitar la replicación con Site Recovery, puede que no esté disponible por uno de los siguientes motivos:

  • Dos máquinas virtuales con el mismo UUID de instancia: si dos máquinas virtuales en vCenter tienen el mismo UUID de instancia, en Azure Portal se muestra la primera máquina virtual detectada por el servidor de configuración. Para solucionar este problema, asegúrese de que no haya dos máquinas virtuales con el mismo UUID de instancia. Este escenario sucede habitualmente en instancias donde una máquina virtual de copia de seguridad se activa y se registra en nuestros registros de detección. Consulte Azure Site Recovery VMware-to-Azure: How to clean up duplicate or stale entries (De VMware a Azure en Azure Site Recovery: cómo limpiar entradas duplicadas u obsoletas) para solucionarlo.
  • Credenciales de usuario de vCenter incorrectas: Asegúrese de que ha agregado las credenciales correctas de vCenter al configurar el servidor de configuración mediante la plantilla OVF o la instalación unificada. Para comprobar las credenciales que ha agregado durante la instalación, consulte Modificación de las credenciales para la detección automática.
  • Privilegios de vCenter insuficientes: Si los permisos proporcionados para acceder a vCenter no son los necesarios, es posible que no se puedan detectar las máquinas virtuales. Asegúrese de que los permisos descritos en Preparación de una cuenta de detección automática se agregan a la cuenta de usuario de vCenter.
  • Servidores de administración de Azure Site Recovery: si la máquina virtual se usa como servidor de administración con al menos uno (o más) de los siguientes roles: servidor de configuración, servidor de procesos de escalabilidad horizontal o servidor de destino principal, no podrá seleccionar la máquina virtual en el portal. Los servidores de administración no se pueden replicar.
  • Máquina virtual ya protegida o conmutada por error mediante servicios de Azure Site Recovery: Si la máquina virtual ya se ha conmutado por error o ya está protegida mediante Site Recovery, no estará disponible para seleccionarla para la protección en el portal. Asegúrese de que la máquina virtual que busca en el portal no esté aún protegida por ningún otro usuario o en otras suscripciones.
  • vCenter no conectado: compruebe si vCenter está en un estado conectado. Para ello, vaya al almacén de Recovery Services > Infraestructura de Site Recovery > Servidores de configuración > Haga clic en el servidor de configuración correspondiente > se abrirá una hoja a la derecha con detalles acerca de los servidores asociados. Compruebe si vCenter está conectado. Si está en un estado "No conectado", resuelva el problema y, después, actualice el servidor de configuración en el portal. Una vez hecho esto, la máquina virtual no se mostrará en el portal.
  • ESXi apagado: si el host ESXi en el que reside la máquina virtual está apagado, la máquina virtual no se muestra ni se puede seleccionar en Azure Portal. Encienda el host ESXi y actualice el servidor de configuración en el portal. Una vez hecho esto, la máquina virtual se mostrará en el portal.
  • Reinicio pendiente: si la máquina virtual está pendiente de reiniciarse, no se podrá seleccionar la máquina en Azure Portal. Asegúrese de completar las actividades de reinicio pendiente y actualice el servidor de configuración. Una vez hecho esto, la máquina virtual se mostrará en el portal.
  • Dirección IP no encontrada o la máquina no tiene ninguna dirección IP: si la máquina virtual no tiene ninguna dirección IP válida asociada, no podrá seleccionar la máquina en Azure Portal. Asegúrese de asignar una dirección IP válida a la máquina virtual y actualice el servidor de configuración. También podría deberse a que el equipo no tiene ninguna dirección IP válida asociada a una de sus NIC. Asigne una dirección IP válida a todas las NIC o quite la NIC que falte a la IP. Una vez hecho esto, la máquina virtual se mostrará en el portal.

Solución de problemas de máquinas virtuales protegidas que aparecen atenuadas en Portal

Las máquinas virtuales que se replican en Site Recovery no están disponibles en Azure Portal si hay entradas duplicadas en el sistema. Más información sobre cómo eliminar entradas obsoletas y resolver el problema.

Otra razón podría ser que la máquina se clonó. Cuando las máquinas se mueven entre un hipervisor y si cambia el identificador de BIOS, el agente de movilidad bloquea la replicación. La replicación de máquinas clonadas no es compatible con Site Recovery.

No se ha producido ningún punto de recuperación consistente entre bloqueos para la máquina virtual en los últimos "XXX" minutos

A continuación se muestra una lista de algunos de los problemas más comunes:

Problemas de replicación inicial [error 78169]

Además de confirmar que no hay problemas relacionados con la conectividad, el ancho de banda o la sincronización de hora, asegúrese de lo siguiente:

  • Ningún software antivirus está bloqueando Azure Site Recovery. Obtenga más información sobre las exclusiones de carpeta necesarias para Azure Site Recovery.

Máquinas de origen con una elevada renovación [error 78188]

Causas posibles:

  • La tasa de cambio de datos (bytes de escritura/s) de los discos enumerados de la máquina virtual es superior a los límites de Azure Site Recovery admitidos para el tipo de cuenta de almacenamiento de destino de replicación.
  • Hay un pico repentino en el abandono, motivo por el cual hay una gran cantidad de datos pendiente de carga.

Para resolver el problema:

  • Asegúrese de que el tipo de cuenta de almacenamiento de destino (Standard o Premium) se haya aprovisionado según el requisito de abandono en el origen.

  • Si ya está replicando en un disco administrado Premium (tipo asrseeddisk), asegúrese de que el tamaño del disco admita la tasa de renovación observada en función de los límites de Site Recovery. Puede aumentar el tamaño de asrseeddisk si es necesario. Siga estos pasos:

    • Vaya a la hoja Discos de la máquina replicada afectada y copie el nombre del disco de réplica.
    • Vaya a este disco administrado de réplica.
    • Es posible que vea un mensaje emergente en la hoja Información general que indica que se ha generado una dirección URL de SAS. Haga clic en este mensaje emergente y cancele la exportación. Omita este paso si no aparece el mensaje emergente.
    • En cuanto se revoque la dirección URL de SAS, vaya a la hoja Configuración del disco administrado y aumente el tamaño para que Azure Site Recovery admita el abandono observado en el disco de origen.
  • Si el abandono observado es temporal, espere unas horas a que la carga de datos pendientes se ponga al día y se creen puntos de recuperación.

  • Si el disco contiene datos no críticos como registros temporales, datos de prueba, etc., considere la posibilidad de mover estos datos a otro lugar o excluir completamente este disco de la replicación.

  • Si el problema persiste, use Deployment Planner de Site Recovery como ayuda para planear la replicación.

Máquinas de origen sin latido [error 78174]

Esto sucede cuando el agente de movilidad de Azure Site Recovery en la máquina de origen no se comunica con el servidor de configuración (CS).

Para resolver el problema, use los siguientes pasos para comprobar la conectividad de red de la máquina virtual de origen con el servidor de configuración:

  1. Confirme que la máquina de origen se está ejecutando.

  2. Inicie sesión en la máquina de origen con una cuenta que tenga privilegios de administrador.

  3. Confirme que los siguientes servicios se están ejecutando y, si no es así, reinícielos:

    • Svagents (agente de InMage Scout VX)
    • Servicio de aplicación de InMage Scout
  4. En la máquina de origen, examine los registros en la ubicación de los detalles del error:

    C:\Archivos de programa (X86)\Microsoft Azure Site Recovery\agent\svagents.log

Servidor de procesos sin latido [error 806]

En caso de que no haya latido en el servidor de procesos (PS), compruebe lo siguiente:

  1. La máquina virtual del servidor de procesos está en funcionamiento

  2. Compruebe los siguientes registros en el servidor de procesos para obtener información detallada del error:

    C:\ProgramData\ASR\home\svsystems\eventmanager*.log
    y
    C:\ProgramData\ASR\home\svsystems\monitor_protection*.log

Servidor de destino maestro sin latido [error 78022]

Esto sucede cuando el agente de movilidad de Azure Site Recovery en el destino maestro no se comunica con el servidor de configuración.

Para resolver el problema, use los siguientes pasos para comprobar el estado del servicio:

  1. Confirme que la máquina virtual del destino maestro se está ejecutando.
  2. Inicie sesión en la máquina virtual del destino maestro con una cuenta que tenga privilegios de administrador.
    • Confirme que el servicio svagents se está ejecutando. Si se está ejecutando, reinicie el servicio.

    • Consulte los registros en la ubicación para obtener información detallada del error:

      C:\Archivos de programa (X86)\Microsoft Azure Site Recovery\agent\svagents.log

  3. Para registrar el destino maestro en el servidor de configuración, vaya a la carpeta %PROGRAMDATA%\ASR\Agent y ejecute lo siguiente en el símbolo del sistema:
    cmd
    cdpcli.exe --registermt
    
    net stop obengine
    
    net start obengine
    
    exit
    

No se pudo habilitar correctamente la protección para la máquina virtual [error 78253]

Este error puede producirse si una directiva de replicación no se ha asociado correctamente al servidor de configuración. También podría ocurrir si la directiva asociada al servidor de configuración no es válida.

Para confirmar la causa de este error, vaya al almacén de recuperación > administre la infraestructura de Site Recovery y, a continuación, vea las directivas de replicación de las máquinas físicas y VMware para comprobar el estado de las directivas configuradas.

Para resolver el problema, puede asociar la directiva al servidor de configuración en uso o crear una nueva directiva de replicación y asociarla. Si la directiva no es válida, puede desasociarla y eliminarla.

Error ID 78144: No hay ningún punto de recuperación coherente con la aplicación disponible para la VM en los XXX últimos minutos

Se han realizado mejoras en las versiones del agente de movilidad9.23 y 9.27 para controlar los comportamientos de errores de instalación de VSS. Asegúrese de que está en las versiones más recientes para obtener la mejor orientación sobre la solución de errores de VSS.

A continuación se enumeran algunos de los problemas más comunes:

Causa 1: Incidencia conocida en SQL Server 2008/2008 R2

Solución: existe un problema conocido en SQL Server 2008/2008 R2. Consulte este artículo de KB Copia de seguridad de ASR Agent u otros VSS no componente falla en un servidor que aloja SQL Server 2008 R2

Causa 2: 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

Solución: consulte el artículo de Kb

Solución: consulte el artículo de KB

Causa 3: Incidencia conocida en SQL Server 2016 y 2017

Solución: consulte el artículo de Kb

Causa 4: La coherencia de aplicaciones no está habilitada en servidores Linux

Solució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:\Archivos de programa (x86)\Microsoft Azure Site Recovery\agent\Application Data\ApplicationPolicyLogs\vacp.log

¿Cómo buscar los errores en el archivo? Busque la cadena "vacpError" abriendo el archivo vacp.log en un editor

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 indica el error como se muestra:

VSS Writer no está instalado - Error 2147221164

Solución: para generar una etiqueta de coherencia de la aplicación, Azure Site Recovery usa el Servicio de instantáneas de volumen de Microsoft (VSS). 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. En caso de que el servicio del proveedor de VSS no esté instalado, la creación de instantáneas de coherencia de la aplicación genera el id. 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

Solución: para generar una etiqueta de coherencia de la aplicación, Azure Site Recovery usa el Servicio de instantáneas de volumen de Microsoft (VSS). 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. En caso de que el servicio del proveedor de VSS esté deshabilitado, la creación de instantáneas de coherencia de las aplicaciones generará el id. de 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

VSS PROVIDER NOT_REGISTERED - Error 2147754756

Solución: para generar una etiqueta de coherencia de la aplicación, Azure Site Recovery usa el Servicio de instantáneas de volumen de Microsoft (VSS). Compruebe si el servicio de proveedor VSS de Azure Site Recovery está instalado o no.

  • Vuelva a intentar la instalación del proveedor con los comandos siguientes:
  • Desinstale el proveedor existente: C:\Archivos de programa (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Uninstall.cmd
  • Vuelva a instalar: C:\Archivos de programa (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 siguientes servicios: Servicio VSS, Proveedor VSS de Azure Site Recovery, Servicio VDS

Id. de error 95001: se encontraron permisos insuficientes

Este error se produce al intentar habilitar la replicación y las carpetas de la aplicación no tienen permisos suficientes.

Solución: para resolver este problema, asegúrese de que el usuario IUSR tenga el rol de propietario para todas las carpetas mencionadas a continuación:

  • C\ProgramData\Microsoft Azure Site Recovery\private
  • El directorio de instalación. Por ejemplo, si el directorio de instalación es la unidad F, proporcione los permisos correctos para:
    • F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems
  • La carpeta \pushinstallsvc en el directorio de instalación. Por ejemplo, si el directorio de instalación es la unidad F, proporcione los permisos correctos para:
    • F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\pushinstallsvc
  • La carpeta \etc en el directorio de instalación. Por ejemplo, si el directorio de instalación es la unidad F, proporcione los permisos correctos para:
    • F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\etc
  • C:\Temp
  • C:\thirdparty\php5nts
  • Todos los elementos en la siguiente ruta de acceso:
    • C:\thirdparty\rrdtool-1.2.15-win32-perl58\rrdtool\Release*

Solución de problemas y control de cambios de tiempo en servidores replicados

Este error se produce cuando el tiempo de la máquina de origen avanza y, después, retrocede en poco tiempo, para corregir el cambio. Es posible que no observe el cambio, ya que la hora se corrige muy rápidamente.

Solución: Para resolver este problema, espere hasta que el tiempo del sistema cruce el tiempo futuro sesgado. Otra opción es deshabilitar y habilitar la replicación una vez más, lo que solo es factible para la replicación reenviada (datos replicados desde el entorno local a Azure) y no es aplicable a la replicación inversa (datos replicados desde Azure a un entorno local).

Pasos siguientes

Si necesita más ayuda, publique su pregunta en la página de preguntas y respuestas de Microsoft sobre Azure Site Recovery. Contamos con una comunidad activa y uno de nuestros ingenieros puede ayudarle.