¿Por qué mi proceso de replicación de Application Migration Service o Elastic Disaster Recovery se atasca al 100 % con el mensaje «Finalizing Initial Sync»?

Descripción breve

Cuando el proceso de replicación se atasca al 100 % durante las sincronizaciones de Application Migration Service o Elastic Disaster Recovery, aparecen los siguientes errores:

• «Finalizing Initial Sync - Flushing Backlog»
• «Finalizing Initial Sync - Creating First Launchable Snapshot»

Resolución

Nota: Si se muestran errores al ejecutar comandos de la Interfaz de la línea de comandos de AWS (AWS CLI), consulta Solución de problemas de AWS CLI. Además, asegúrate de utilizar la versión más reciente de la AWS CLI.

Solución del error «Finalizing Initial Sync - Flushing Backlog»

Espera hasta que las tareas pendientes terminen de eliminarse para que empiece la sincronización.

Si la máquina de origen tiene un uso intensivo de escritura, es posible que aumenten las tareas pendientes. Si la máquina está bloqueada en el estado «Finalizing Initial Sync», prueba la velocidad de replicación de Application Migration Service o Elastic Disaster Recovery. Asimismo, calcula el ancho de banda requerido para todas las máquinas de origen que se están replicando. Asegúrate de que el rendimiento de red de la instancia de replicación sea suficiente.

Para comprobar la configuración de replicación, sigue estos pasos:

1. Abre la consola de Application Migration Service o Elastic Disaster Recovery.
2. En el panel de navegación, elige Servidores de origen.
3. Elige Editar la configuración de replicación.
4. Comprueba si la limitación del ancho de banda de la red está configurada en Limitar el ancho de banda. Si no necesitas limitar el ancho de banda, selecciona No limitar el ancho de banda. Si necesitas limitar el ancho de banda, asegúrate de establecer el valor en el ancho de banda mínimo requerido. Para obtener más información, consulta Data routing and throttling (Enrutamiento y limitación de datos) para Application Migration Service o Throttle network bandwidth (Limitación del ancho de banda de red) para Elastic Disaster Recovery.

Utiliza las métricas de Amazon CloudWatch para comprobar el uso de la red y el disco del servidor de replicación. Si un recurso limita el servidor, utiliza un servidor de replicación específico o un tipo de servidor de replicación más grande. O bien, elige almacenamiento basado en SSD. Para más información, consulta AWS Application Migration Service best practices (Prácticas recomendadas de AWS Application Migration Service) o Change staging disk type (Cambio del tipo de disco transitorio).

Para comprobar el servidor de replicación que usa una máquina de origen específica, ejecuta el siguiente comando en la máquina de origen según tu sistema operativo (SO).

Linux:

netstat -anp | grep ":1500"

Windows:

netstat -ano | findstr ":1500"

Anota la dirección IP remota a la que se conecta la máquina a través del puerto 1500.

O bien, ejecuta el siguiente comando en función de tu sistema operativo para revisar el archivo agent.log.0 en la máquina de origen e identificar el servidor de replicación exacto que se está utilizando.

Linux:

sudo cat /var/lib/aws-replication-agent/agent.log.0 | grep :1500 | tail -n 1

Windows:

findstr /L ":1500" "C:\Program Files (x86)\AWS Replication Agent\agent.log.0"

Solución del error «Finalizing Initial Sync - Creating First Launchable Snapshot»

Comprobación de los permisos de la política de IAM del usuario

Asegúrate de que la política de AWS Identity and Access Management (IAM) del usuario tenga todos los permisos necesarios para ejecutar las API de Amazon Elastic Compute Cloud (Amazon EC2).

Comprueba las credenciales del usuario para Application Migration Service o Elastic Disaster Recovery. O bien, consulta el historial de eventos de AWS CloudTrail para buscar los errores de API que se produjeron en el usuario.

Comprobación de los puntos de enlace de Amazon EC2

Asegúrate de que el servidor de replicación pueda comunicarse con los puntos de enlace de Amazon EC2 para Application Migration Service o Elastic Disaster Recovery en tu región de AWS.

Para probar la conectividad a los puntos de enlace del servicio, sigue estos pasos:

1. Inicia una nueva instancia de Linux en la misma subred que tu área transitoria.
2. Inicia sesión en la nueva instancia y, a continuación, ejecuta los siguientes comandos:

   dig ec2.us-east-1.amazonaws.com  
   telnet ec2.us-east-1.amazonaws.com 443  
   wget https://ec2.us-east-1.amazonaws.com

   Nota: Sustituye us-east-1 por tu región. Si se produce un error en alguno de los comandos anteriores, ve a la siguiente sección para solucionar problemas de conectividad de red. Confirma que la configuración de la nube virtual privada (VPC), la subred, el grupo de seguridad, la lista de control de acceso de la red (ACL de la red) y la tabla de enrutamiento coincida con la configuración de replicación. Si la configuración es incorrecta, podría bloquear la comunicación con los puntos de enlace de Amazon EC2 desde los servidores de replicación.

Identificación de los bloqueadores de conectividad de red correspondientes a un servidor de replicación que hayas iniciado en una subred pública

Asegúrate de que el grupo de seguridad, las ACL de la red y la tabla de enrutamiento permitan la comunicación con los puntos de enlace de Amazon EC2 en el puerto TCP 443.

Comprueba que los atributos enableDnsHostnames y enableDnsSupport estén establecidos en true en el nivel de VPC. Ejecuta el siguiente comando describe-vpc-attribute de la AWS CLI para comprobar el atributo enableDnsHostnames:

aws ec2 describe-vpc-attribute --vpc-id vpc-abcdef --attribute enableDnsHostnames   

Nota: Sustituye vpc-abcdef por tu ID de VPC.

Resultado de ejemplo:

$ aws ec2 describe-vpc-attribute --vpc-id vpc-abcdef --attribute enableDnsHostnames  
{   
 "VpcId": "vpc-a01106c2",  
 "EnableDnsHostnames": {   
 "Value": true  
 }   
}

Ejecuta el siguiente comando describe-vpc-attribute para comprobar el atributo enableDnsSupport:

aws ec2 describe-vpc-attribute --vpc-id vpc-abcdef --attribute enableDnsSupport

Nota: Sustituye vpc-abcdef por tu ID de VPC.

Resultado de ejemplo:

$ aws ec2 describe-vpc-attribute --vpc-id vpc-abcdef --attribute enableDnsSupport     
{  
 "VpcId": "vpc-a01106c2",   
 "EnableDnsSupport": {  
 "Value": true   
 }  
}

Si los atributos no están configurados en «true», ejecuta el siguiente comando modify-vpc-attribute para activarlos:

aws ec2 modify-vpc-attribute --vpc-id vpc-abdcef --enable-dns-hostnames "{\"Value\":true}"

Nota: Sustituye vcp-abcdef por tu ID de VPC y enable-dns-hostnames por el atributo que no esté establecido en true.

Identificación de los bloqueadores de conectividad de red correspondientes a un servidor de replicación que hayas iniciado en una subred privada

Comprueba que el grupo de seguridad, las ACL de la red y la tabla de enrutamiento permitan la comunicación con los puntos de enlace privados de Amazon EC2 en el puerto TCP 443. Si has configurado una puerta de enlace o instancia de NAT en la tabla de enrutamiento, comprueba que funcione el tráfico saliente al punto de enlace de Amazon EC2 en el puerto TCP 443.

Comprueba si el tráfico saliente pasa por una puerta de enlace privada virtual o de tránsito. Si es así, asegúrate de que la tabla de enrutamiento permita el tráfico a los puntos de enlace de Amazon EC2 en el puerto TCP 443. Comprueba también si el firewall bloquea la comunicación.

Si la VPC tiene puntos de conexión de VPC de interfaz, asegúrese de que hay comunicación entre los puntos de conexión de Amazon EC2 en el puerto TCP 443 a través de una red privada. Comprueba que has establecido enableDnsHostnames y enableDnsSupport en true en el nivel de la VPC y PrivateDnsEnabled en true en los puntos de enlace de la interfaz de VPC.

Ejecuta el siguiente comando describe-vpc-attribute para comprobar el atributo enableDnsHostnames:

aws ec2 describe-vpc-attribute --vpc-id vpc-abcdef --attribute enableDnsHostnames --query 'EnableDnsHostnames'

Nota: Sustituye vpc-abcdef por tu ID de VPC.

Resultado de ejemplo:

$ aws ec2 describe-vpc-attribute --vpc-id vpc-a01106c2 --attribute enableDnsHostnames --query 'EnableDnsHostnames'  

{   
 "Value": true  
}

Ejecuta el siguiente comando describe-vpc-attribute para comprobar el atributo enableDnsSupport:

aws ec2 describe-vpc-attribute --vpc-id vpc-abcdef --attribute enableDnsSupport --query 'EnableDnsSupport'

Nota: Sustituye vpc-abcdef por tu ID de VPC.

Resultado de ejemplo:

$ aws ec2 describe-vpc-attribute --vpc-id vpc-a01106c2 --attribute enableDnsSupport --query 'EnableDnsSupport'  

{   
 "Value": true  
}

Ejecuta el siguiente comando describe-vpc-attribute para comprobar el atributo PrivateDnsEnabled:

aws ec2 describe-vpc-endpoints --vpc-endpoint-ids vpce-12345abcde --query 'VpcEndpoints[0].PrivateDnsEnabled'  

Nota: Sustituye vpce-12345abcde por el punto de enlace de VPC.

Resultado de ejemplo:

true

Si los atributos no están configurados en «true», ejecuta el siguiente comando modify-vpc-attribute para modificarlos:

aws ec2 modify-vpc-attribute --vpc-id vpc-abdcef --enable-dns-hostnames "{\"Value\":true}"

Nota: Sustituye vcp-abcdef por tu ID de VPC y enable-dns-hostnames por el atributo que no esté establecido en true.

Comprobación para saber si hay cambios recientes en la Configuración de replicación

Comprueba los cambios recientes en la Configuración de replicación de Application Migration Service o Elastic Disaster Recovery. Consulta el historial de eventos de CloudTrail para ver la llamada a la API UpdateReplicationConfiguration para identificar los cambios. Utiliza el servidor de origen para filtrar el nombre del recurso. Por ejemplo, comprueba si hay una etiqueta no válida insertada en el campo Etiquetas de recursos de replicación. Para obtener una lista de los caracteres permitidos, consulta Restricciones de las etiquetas.

Comprobación para saber si se utiliza la configuración de proxy correcta

Si tus servidores de replicación utilizan un servidor proxy, confirma que la configuración del proxy permite la comunicación con los puntos de enlace regionales de Amazon EC2 en el puerto TCP 443.

Asegúrate de que la lista de permisos de autenticación e interceptación de SSL incluya mgn.region.amazonaws.com para Application Service Migration y drs.region.amazonaws.com para Elastic Disaster Recovery.

Nota: Sustituye region por tu región.

Para más información, consulta Can a proxy server be used between the source server and the AWS Application Migration Service console? (¿Se puede utilizar un servidor proxy entre el servidor de origen y la consola de AWS Application Migration Service?) Consulta también Can a proxy server be used between the source server and the Elastic Disaster Recovery Console? (¿Se puede utilizar un servidor proxy entre el servidor de origen y la consola de Elastic Disaster Recovery?)

Comprobación del agente de replicación de AWS

Confirma que el agente de replicación de AWS funciona correctamente en la máquina de origen. Para identificar los problemas, comprueba si hay errores en los registros del agente de replicación de AWS. Puedes encontrar los registros del agente de replicación de AWS en las siguientes ubicaciones de archivos:

• Para ver los registros del agente de replicación de Linux, consulta /var/lib/aws-replication-agent/agent.log.0.
• Para ver los registros del agente de replicación de Windows, comprueba C:\Archivos de programa (x86)\Agente de replicación de AWS\agent.log.0

Comprobación de problemas con Service Quotas de Amazon EC2

Si superas una cuota de servicio en Application Migration Service o Elastic Disaster Recovery, los servicios no podrán crear una instantánea de recuperación que se pueda iniciar. También es posible que encuentres problemas de limitación o exceso de velocidad de la API. Consulta el historial de eventos de CloudTrail para identificar los problemas de limitación del ancho de banda o la cuota de servicio. Si es necesario, solicita un aumento de cuota.