¿Cómo puedo solucionar problemas de retraso de replicación o una acumulación de trabajo pendiente en mi servidor fuente Linux para el Application Migration Service?
Observo una demora o trabajo pendiente en mi servidor de origen Linux al replicar datos mediante AWS Application Migration Service.
Descripción breve
Estos son los factores que contribuyen al retraso en la replicación cuando se replican datos de un servidor de origen a un servidor de destino:
- Velocidad de enlace ascendente y disponibilidad de ancho de banda: La velocidad de la conexión de red entre el servidor de origen y el servidor de replicación puede tener un impacto significativo en el rendimiento de la replicación. Las conexiones lentas pueden impedir que se complete el proceso de replicación. Además, el ancho de banda limitado restringe la cantidad de datos que se pueden replicar en un tiempo determinado.
- Cambios en el disco durante la replicación: Durante el proceso de replicación, el servidor de origen puede seguir escribiendo nuevos datos en los discos. Si se produce un fuerte aumento de la cantidad de datos nuevos que escribe el servidor de origen, los datos se acumulan y crean una demora importante. AWS Replication Agent debe enviar este trabajo pendiente en la sincronización inicial. Cuanto más trabajo pendiente haya, más tardará en completar la replicación de datos.
- Velocidad de E/S de los discos de almacenamiento: Durante el proceso de replicación, AWS Replication Agent lee los bloques de almacenamiento de los discos y transmite los datos al servidor de replicación. Sin embargo, una alta latencia de lectura en los discos del servidor de origen podría afectar a la velocidad y eficacia de la replicación de datos. Los discos de baja velocidad provocan retrasos y los discos de alta velocidad mejoran la velocidad de replicación.
- Carga en el servidor de origen: La contención de recursos en el servidor de origen puede provocar una alta utilización de la CPU, consumo de memoria, demoras de E/S u otras limitaciones de recursos. Por ejemplo, una utilización elevada de la CPU puede provocar cuellos de botella en la replicación. Esto se debe a que el sistema se esfuerza por asignar recursos de CPU entre AWS Replication Agent y otros procesos. Del mismo modo, un consumo elevado de memoria puede hacer que el sistema traslade las páginas de memoria al disco. Esto provoca un aumento de la demora de E/S y una ralentización del proceso de replicación.
- Recursos de replicación infradotados: Los volúmenes transitorios de Amazon Elastic Block Store (Amazon EBS) con menor rendimiento e IOPS pueden provocar una alta latencia de lectura y escritura, así como colas de espera más largas. Todos estos problemas afectan al rendimiento de la replicación. Además, un tipo de instancia de servidor de replicación con bajo rendimiento de red y ancho de banda de Amazon EBS provoca problemas de rendimiento en la replicación.
Solución
Para determinar la razón subyacente de la demora, primero realice comprobaciones en el servidor de origen. A continuación, realice comprobaciones en el área transitoria.
Comprobaciones del servidor de origen
Compruebe que el servidor de origen ha arrancado y está en funcionamiento
Asegúrese de que el Servidor de Origen para la migración ha arrancado y está en funcionamiento.
Compruebe que el servidor de origen puede establecer una conexión SSL con el punto de conexión de la API del Application Migration Service regional y el servidor de replicación
Asegúrese de que los certificados SSL no se interceptan ni cambian en ningún punto entre el servidor de origen y el punto de conexión de la API del Application Migration Service. Y, asegúrese de que los certificados SSL no se interceptan y cambian entre el servidor de origen y el servidor de replicación. Para ello, ejecute el siguiente comando:
# echo -n | openssl s_client -connect mgn.<region>.amazonaws.com:443 # echo -n | openssl s_client -connect <replication server IP>:1500
Nota: Utilice el comando que aparece en la sección Verificar conexiones TCP activas para encontrar la dirección IP del servidor de replicación.
Compruebe que todos los procesos de AWS Replication Agent se están ejecutando
Ejecute el siguiente comando para listar los servicios de AWS Replication Agent en ejecución:
# ps -u aws-replication
La siguiente salida muestra los procesos de AWS Replication Agent que deberían estar ejecutándose:
PID TTY TIME CMD 30878 ? 00:00:00 update_onprem_v 30879 ? 00:00:00 run_linux_migra 30880 ? 00:00:00 tailer 30881 ? 00:04:45 java 30902 ? 00:00:01 tailer 30904 ? 00:00:00 run_linux_migra 30905 ? 00:00:10 update_onprem_v 31023 ? 00:00:00 tail
Comprobar las conexiones TCP activas
Ejecute el siguiente comando para verificar que hay cinco conexiones TCP activas establecidas con el servidor de replicación en el puerto TCP 1500.
# sudo netstat -anp | awk '$5 ~ /:1500$/ {print}'
Compruebe la salida de comandos para las conexiones activas:
tcp6 0 0 172.31.1.39:54814 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54828 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54832 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54812 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54800 172.31.0.82:1500 ESTABLISHED 30881/java
Compruebe la utilización de la CPU en el núcleo de la CPU donde se ejecuta AWS Replication Agent
AWS Replication Agent es un proceso de un solo subproceso que funciona en un núcleo de CPU. Si la utilización de la CPU es alta en el núcleo donde se ejecuta AWS Replication Agent, se ralentizará la replicación de datos.
1. Ejecute los siguientes comandos y luego revise el resultado para determinar lo siguiente:
- El ID del proceso de AWS Replication Agent.
- El núcleo de la CPU (indicado por psr) en el que se está ejecutando.
# ps --pid $(pidof /var/lib/aws-replication-agent/jre/bin/java) -o psr,pid,comm # mpstat -P <psr column value> 3
2. A continuación, compruebe la utilización de la CPU del núcleo de CPU identificado.
Compruebe el rendimiento del disco en el servidor de origen
Si el rendimiento de lectura (rMB/s) de los discos de origen es bajo, se leerán y replicarán menos datos. Anote cualquier aumento en las métricas de profundidad de E/S (avgqu-sz) y tiempo de espera de E/S (await). Puede utilizar las herramientas sar o iostat para medir el rendimiento de lectura del disco:
# iostat -myx 3 # sar -dp 2
Compruebe si en el servidor de origen hay un pico de operaciones de escritura
Un pico de operaciones de escritura en el servidor de origen podría provocar un aumento de la demora de replicación. Este crecimiento continúa hasta que AWS Replication Agent descarga todos los datos escritos en el servidor de replicación. Ejecute la prueba iostat de forma periódica para determinar cuál es la carga de E/S a medida que cambia la carga de trabajo. Si el rendimiento de escritura (wMB/s) supera el rendimiento de red disponible, se produce una demora en la replicación.
Nota: Para calcular el ancho de banda necesario desde el servidor de origen hasta el servidor de replicación, consulte Cálculo del ancho de banda necesario para el puerto TCP 1500.
Compruebe la velocidad de replicación y el ancho de banda disponible desde el servidor de origen hasta la subred del área transitoria
1. En su región de AWS de destino, lance una instancia de prueba de Amazon Elastic Compute Cloud (Amazon EC2) utilizando la AMI de publicación CE-ssl-speedtest. La instancia EC2 debe ser del mismo tipo que el servidor de replicación.
2. Seleccione la misma subred que la utilizada en la configuración de replicación de su servidor de origen.
3. Asegúrese de que el grupo de seguridad permite el acceso entrante al puerto TCP 1500.
4. En el servidor de origen, configure la CLI de SpeedTest como se muestra en el siguiente ejemplo:
# cd /tmp # git clone https://github.com/librespeed/speedtest-cli.git # cd speedtest-cli/ # ls -l # ./build.sh # cat << EOF >> ./servers.json [ { "id": 1, "name": "PHP Backend", "server": "https://<test server private IP>:1500/speedtest/", "dlURL": "/garbage.php", "ulURL": "/empty.php", "pingURL": "/empty.php" } ] EOF
Nota: En el ejemplo anterior, asegúrese de sustituir la dirección IP del servidor de prueba. Si está utilizando la IP pública del servidor de prueba para una prueba de velocidad, incluya "getIpURL": "/getIP.php" después de la línea "pingURL".
5. Ejecute la CLI de LibreSpeed como se muestra en el siguiente ejemplo para comprobar la velocidad de replicación:
# ./out/librespeed-cli-linux-amd64 —local-json ./servers.json —server 1 —no-icmp —skip-cert-verify —simple Ping: 11.00 ms Jitter: 0.00 ms Download rate: 503.84 Mbps Upload rate: 493.56 Mbps
Comprobación de un servidor fuente que se cerró de forma inesperada
Si un servidor fuente se apaga de forma inesperada, AWS Replication Agent vuelve a escanear todos los discos después de que se reinicie el servidor. AWS Replication Agent vuelve a leer los discos, y la demora aumenta continuamente hasta que se completa el nuevo escaneo. Para más información, consulte ¿Qué sistemas operativos Windows y Linux admiten la opción de no volver a escanear al reiniciar?
Compruebe si se ha actualizado el kernel
Si se actualiza el kernel en el servidor de origen y se reinicia el servidor, AWS Replication Agent no se ejecutará. La versión del kernel en ejecución coincide con la versión del kernel para la que se compiló el controlador de AWS Replication Agent durante la instalación del agente.
Ejecute los siguientes comandos para verificar que la versión del kernel en ejecución coincide con la versión del kernel para la que se compiló el controlador de AWS Replication Agent:
$ uname -r $ modinfo -F vermagic /var/lib/aws-replication-agent/aws-replication-driver.ko
Nota: vermagic se utiliza para verificar en qué versión del kernel está compilado el controlador del kernel.
Compruebe que el puerto TCP 1500 no está bloqueado
Asegúrese de que el puerto TCP 1500 no está bloqueado en la salida desde el servidor de origen al servidor de replicación.
Revise los registros del agente de MGN
Inspeccione los registros del agente de MGN en busca de problemas de conectividad con el servidor de replicación en el puerto TCP 1500. Compruebe también si hay irregularidades en la replicación que indiquen una pérdida frecuente de conexión. Tras identificar estos problemas, revise la topología de la red para investigar más a fondo.
Compruebe que los dispositivos intermedios no tienen una MTU más baja.
Confirme que ninguno de los dispositivos intermedios de la ruta de replicación tiene una MTU más baja. Una MTU más baja reduce la velocidad de replicación y causa demoras durante el proceso. Una práctica recomendada es mantener un tamaño de MTU coherente en toda la ruta de replicación. Si un dispositivo de la ruta tiene una MTU más baja, actualícelo o sustitúyalo por un dispositivo con una MTU más alta.
Nota: Si está replicando a través de la red pública de Internet, asegúrese de que la MTU es 1500. 1500 es la MTU más alta que admiten las puertas de enlace de Internet, el emparejamiento y las VPN. Las tramas gigantes solo funcionan dentro de Amazon Virtual Private Cloud (Amazon VPC) o AWS Direct Connect y tienen sus propias limitaciones. Para más información, consulte los siguientes artículos:
Compruebe que la limitación del ancho de banda de la red está desactivada en la configuración de replicación del servidor fuente.
La limitación del ancho de banda debe estar desactivada en la configuración de replicación del servidor fuente.
La activación de la limitación del ancho de banda en el servidor de origen limita la velocidad de transferencia de datos de AWS Replication Agent. Esto puede dar lugar a un crecimiento constante o estancado de la demora si hay acumulación de trabajo pendiente en el servidor de origen. Para mantener un ancho de banda constante y limitado para la transferencia de datos, active la limitación del ancho de banda de la red.
Para comprobar si existe limitación del ancho de banda, siga estos pasos:
1. Abra la consola de Application Migration Service.
2. Seleccione Servidores de origen y, a continuación, seleccione el servidor de origen.
3. Seleccione la pestaña Configuración de replicación.
3. Si la función Limitar el ancho de banda de la red está activada, asegúrese de que el valor limitado es igual o superior al ancho de banda necesario para la replicación de datos. Para más información, consulte la nota de la sección anterior, Compruebe si el servidor de origen presenta un pico de operaciones de escritura.
Comprobación de los recursos del área transitoria
Compruebe que el puerto TCP 1500 no está bloqueado en la entrada
Asegúrese de que el puerto TCP 1500 no tiene la entrada bloqueada en los grupos de seguridad del servidor de replicación.
Nota: Debe completar los siguientes pasos en la consola de Amazon Elastic Compute Cloud (Amazon EC2).
1. Abra la consola de Amazon EC2.
2. Seleccione el grupo de seguridad adjunto a la instancia de replicación.
3. Compruebe que el puerto TCP 1500 de entrada está permitido en el grupo de seguridad adjunto.
Compruebe la métrica NetworkIn de CloudWatch
Si la métrica NetworkIn de Amazon CloudWatch para el servidor de replicación se acerca al límite de ancho de banda, es posible que se produzca una limitación. La limitación da lugar a una menor velocidad de replicación y una demora mayor. Considere la posibilidad de actualizar a un tipo de instancia mayor que pueda asumir el ancho de banda necesario.
Compruebe el rendimiento conjunto y las IOPS de los volúmenes EBS del servidor de replicación.
El rendimiento del servidor de replicación podría verse limitado si el rendimiento conjunto y las IOPS de los volúmenes de Amazon Elastic Block Store (Amazon EBS) superan los límites. Si se produce una limitación, cambie a un tipo de instancia de servidor de replicación que se adapte a sus necesidades de replicación y mantenga el rendimiento sin limitación. Se recomienda utilizar un tipo de instancia optimizado para EBS de la generación actual para los servidores de replicación. En instancias sin rendimiento optimizado para EBS, el tráfico de red compite con el tráfico entre la instancia y los volúmenes de EBS. En las instancias optimizadas para EBS, los dos tipos de tráfico se mantienen separados. Supervise la red del servidor de replicación y las métricas de EBS CloudWatch. Para más información, consulte los siguientes artículos:
Monitorizar las métricas de todos los volúmenes EBS de replicación
Las demoras y el trabajo pendiente se acumulan cuando la velocidad de escritura del volumen del servidor de replicación no puede igualar la velocidad de cambio en el servidor de origen. Para evitar retrasos en la replicación, utilice un tipo de volumen más rápido con mayor IOPS y ancho de banda. Para un rendimiento óptimo del volumen EBS, se recomienda supervisar las métricas de CloudWatch para cada volumen EBS de replicación.
Comprobación de volúmenes EBS creados a partir de una instantánea
Los servidores de replicación que tienen volúmenes EBS creados a partir de una instantánea, pueden tener un aumento de la latencia de las operaciones de E/S la primera vez que se accede a cada bloque. Esta latencia puede provocar un crecimiento lento o estancamiento hasta que finalice el proceso de escaneo. Para más información, consulte Tenga en cuenta la reducción del rendimiento al inicializar volúmenes a partir de instantáneas.
Verifique la cuota de instantáneas en la región de destino
Asegúrese de que su cuenta de AWS no ha alcanzado los límites de cuota de instantáneas en la región de AWS en la que está replicando los servidores de origen. Utilice los siguientes comandos de la interfaz de la línea de comandos de AWS (AWS CLI) para comprobar si ha alcanzado la cuota de instantáneas en la región. En el siguiente ejemplo, sustituya región por su región de AWS de destino:
# aws service-quotas get-service-quota --service-code ebs --quota-code L-309BACF6 --region region --query "Quota.Value" # aws ec2 describe-snapshots --owner-ids self --region region --query "length(Snapshots)"
Nota: Si recibe errores al ejecutar los comandos de AWS CLI, asegúrese de que está utilizando la versión más reciente de AWS CLI.
Información relacionada
Contenido relevante
- OFICIAL DE AWSActualizada hace un año