Comment puis-je résoudre les problèmes de décalage de réplication ou de backlog sur mon serveur source Linux pour l’interface Application Migration Service ?
Je constate un décalage ou un backlog sur mon serveur source Linux lors de la réplication de données à l'aide d'AWS Application Migration Service.
Brève description
Les facteurs suivants contribuent au décalage de réplication et au backlog lors de la réplication de données d'un serveur source vers un serveur cible :
- Vitesse de liaison montante du réseau et disponibilité de la bande passante : La vitesse de connexion réseau entre le serveur source et le serveur de réplication peut avoir un impact significatif sur les performances de réplication. Des connexions lentes peuvent empêcher la fin du processus de réplication. De plus, la bande passante limitée limite la quantité de données que vous pouvez répliquer à un moment donné.
- Modifications du disque lors de la réplication : Pendant le processus de réplication, le serveur source peut continuer à écrire de nouvelles données sur ses disques. En cas de forte augmentation de la quantité de nouvelles données écrites par le serveur source, les données s'accumulent et créent un backlog important. L'agent de réplication AWS doit envoyer ce backlog lors de la synchronisation initiale. Plus le backlog est important, plus la réplication des données prend du temps.
- Vitesse d'E/S des disques de stockage : Pendant le processus de réplication, l'agent de réplication AWS lit les blocs de stockage des disques et transmet les données au serveur de réplication. Toutefois, une latence de lecture élevée sur les disques du serveur source peut avoir un impact sur la vitesse et l'efficacité de la réplication des données. Les disques lents entraînent des retards, tandis que les disques rapides améliorent la vitesse de réplication.
- Charge du serveur source : La contention des ressources sur le serveur source peut entraîner une forte utilisation du processeur, une forte consommation de mémoire, une attente d'E/S ou d'autres contraintes liées aux ressources. Par exemple, une forte utilisation du processeur peut entraîner des problèmes de réplication. En effet, le système a du mal à allouer les ressources du processeur entre l'agent de réplication AWS et les autres processus. De même, une forte consommation de mémoire peut amener le système à échanger des pages de mémoire sur le disque. Cela entraîne une augmentation du temps d'attente des E/S et un ralentissement du processus de réplication.
- Ressources de réplication sous-approvisionnées : Le transit de volumes Amazon Elastic Block Store (Amazon EBS) à un débit et compte tenu d’une valeur IOPS inférieurs peut entraîner une forte latence de lecture et d'écriture et une longue file d'attente. Tous ces problèmes ont une incidence sur les performances de réplication. De plus, un type d'instance de serveur de réplication associé à un débit réseau et une bande passante Amazon EBS faibles entraîne des problèmes de performances de réplication.
Résolution
Pour déterminer la raison sous-jacente du décalage, commencez par vérifier le serveur source. Ensuite, effectuez des vérifications sur la zone de transit.
Vérifications du serveur source
Vérifiez que le serveur source est démarré et en cours d'exécution.
Assurez-vous que le serveur source qui doit servir à la migration est démarré et en cours d'exécution.
Vérifiez que le serveur source peut établir une connexion SSL avec le point de terminaison d'API régional de l’interface Application Migration Service et le serveur de réplication.
Assurez-vous que les certificats SSL ne sont interceptés ou modifiés à aucun moment entre le serveur source et le point de terminaison de API Application Migration Service. Assurez-vous également que les certificats SSL ne sont ni interceptés ni modifiés entre le serveur source et le serveur de réplication. Pour ce faire, exécutez la commande suivante :
# echo -n | openssl s_client -connect mgn.<region>.amazonaws.com:443 # echo -n | openssl s_client -connect <replication server IP>:1500
Remarque : utilisez la commande répertoriée dans la rubrique Vérifier les connexions TCP actives suivante pour trouver l'adresse IP du serveur de réplication.
Vérifiez que tous les processus de l'agent de réplication AWS sont en cours d'exécution.
Exécutez la commande suivante pour répertorier les services de l’agent de réplication AWS en cours d'exécution :
# ps -u aws-replication
La sortie suivante indique les processus de l'agent de réplication AWS à exécuter :
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
Vérifiez les connexions TCP actives
Exécutez la commande suivante pour vérifier que cinq connexions TCP actives sont établies avec le serveur de réplication sur le port TCP 1500.
# sudo netstat -anp | awk '$5 ~ /:1500$/ {print}'
Vérifiez la sortie de commande pour les connexions actives :
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
Vérifiez l'utilisation du processeur sur le cœur du processeur sur lequel s'exécute l'agent de réplication AWS
L'agent de réplication AWS est un processus à fil unique qui fonctionne sur un cœur de processeur à la fois. Si l'utilisation du processeur est élevée sur le cœur où s'exécute l'agent de réplication AWS, la réplication des données ralentit.
1. Exécutez les commandes suivantes, puis examinez la sortie pour déterminer ce qui suit:
- L'ID de processus de l'agent de réplication AWS.
- Le cœur du processeur (indiqué par psr) sur lequel il s'exécute.
# ps --pid $(pidof /var/lib/aws-replication-agent/jre/bin/java) -o psr,pid,comm # mpstat -P <psr column value> 3
2. Vérifiez ensuite l'utilisation du processeur du cœur de processeur identifié.
Vérifiez les performances du disque sur le serveur source.
Si le débit de lecture (rMB/s) est faible sur les disques sources, moins de données sont lues et répliquées. Prenez note de toute éventuelle augmentation de la profondeur des E/S (avgqu-sz) et des ** métriques d'attente (latence) d'**E/S. Vous pouvez utiliser les outils sar ou iostat pour mesurer le débit de lecture du disque :
# iostat -myx 3 # sar -dp 2
Vérifiez le serveur source pour détecter un éventuel pic d'opérations d'écriture.
Un pic d'opérations d'écriture sur le serveur source peut entraîner une augmentation du délai de réplication. Cette croissance se poursuit jusqu'à ce que l'agent de réplication AWS vide toutes les données écrites vers le serveur de réplication. Exécutez régulièrement le test iostat pour déterminer la charge d'E/S en fonction de l'évolution de la charge de travail. Si le débit d'écriture (wMB/s) dépasse le débit réseau disponible, vous constatez un retard de réplication.
**Remarque :**pour calculer la bande passante requise entre le serveur source et le serveur de réplication, consultez la rubrique Calcul de la bande passante requise pour le port TCP 1500.
Vérifiez la vitesse de réplication et la bande passante disponible entre le serveur source et le sous-réseau de la zone intermédiaire
1. Dans votre région AWS cible, lancez une instance de test Amazon Elastic Compute Cloud (Amazon EC2) à l'aide de l'AMI de publication CE-ssl-speedtest. Le type d’instance de l'instance EC2 doit être le même que celui du serveur de réplication.
2. Sélectionnez le même sous-réseau que celui des paramètres de réplication de votre serveur source.
3. Assurez-vous que le groupe de sécurité autorise l'accès entrant au port TCP 1500.
4. Sur le serveur source, configurez l'interface de ligne de commande SpeedTest comme suit :
# 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
**Remarque :dans l'exemple précédent, veillez à remplacer l'adresse IP du serveur de test. Si vous utilisez l'adresse IP publique du serveur de test pour un test de vitesse, incluez « getIpURL » : « /getIP.php » après la ligne **« pingURL ».
5. Exécutez l’interface de ligne de commande LibreSpeed comme suit pour tester la vitesse de réplication :
# ./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
Recherchez un serveur source qui a été arrêté de manière inappropriée
Si un serveur source est arrêté de manière inappropriée, l'agent de réplication AWS réanalyse tous les disques après le redémarrage du serveur. L'agent de réplication AWS relit les disques et le délai augmente continuellement jusqu'à ce que la nouvelle numérisation soit terminée. Pour en savoir plus, consultez Quels systèmes d'exploitation Windows et Linux prennent en charge le no-rescan au redémarrage ?
Vérifiez si une mise à jour du noyau est disponible.
Si le noyau est mis à niveau sur le serveur source et que le serveur est redémarré, l'agent de réplication AWS ne s'exécute pas. La version du noyau en cours d'exécution correspond à la version du noyau pour laquelle le pilote AWS Replication Agent a été compilé lors de l'installation de l'agent.
Exécutez les commandes suivantes pour vérifier que la version du noyau en cours d'exécution correspond à la version du noyau pour laquelle le pilote AWS Replication Agent a été compilé :
$ uname -r $ modinfo -F vermagic /var/lib/aws-replication-agent/aws-replication-driver.ko
**Remarque : **vermagic est utilisé pour vérifier la version du noyau dans laquelle le pilote du noyau est compilé.
Vérifiez que le port TCP 1500 n'est pas bloqué en sortie.
Assurez-vous que le port TCP 1500 n'est pas bloqué en sortie du serveur source vers le serveur de réplication.
Consultez les journaux de l'agent MGN.
Inspectez les journaux de l’agent MGN à la recherche d’éventuels problèmes de connectivité avec le serveur de réplication sur le port TCP 1500. Vérifiez également les irrégularités de réplication révélatrices de pertes de connexion fréquentes. Après avoir identifié ces problèmes, passez en revue la topologie du réseau pour les étudier plus en profondeur.
Vérifiez que l’unité MTU des appareils intermédiaires n’est pas plus faible.
Vérifiez que l’unité MTU d’un périphérique intermédiaire du chemin de réplication n’est pas plus faible. Une unité MTU plus faible réduit la vitesse de réplication et entraîne des retards dans le processus. Il est recommandé de maintenir une taille de MTU constante tout au long du chemin de réplication. Si l’unité MTU d’un périphérique du chemin d’accès est plus faible, mettez-le à jour ou remplacez-le par un périphérique à MTU plus élevée.
**Remarque :**Si vous effectuez une réplication via l'Internet public, assurez-vous que l’unité MTU atteint 1 500. 1 500 est la valeur maximale prise en charge par la passerelle Internet, le peering et le VPN. Les cadres Jumbo ne fonctionnent que dans Amazon Virtual Private Cloud (Amazon VPC) ou AWS Direct Connect et présentent leurs propres limites. Pour en savoir plus, consultez les rubriques suivantes :
Vérifiez que la limitation de bande passante du réseau est désactivée dans les paramètres de réplication du serveur source.
La limitation de bande passante doit être désactivée dans les paramètres de réplication du serveur source.
L'activation de la limitation de bande passante sur le serveur source limite le taux de transfert de données de l'agent de réplication AWS. Elle peut entraîner une augmentation constante ou stagnante du décalage en cas de retard sur le serveur source. Pour maintenir une bande passante constante et limitée pour le transfert de données, activez la limitation de bande passante du réseau.
Pour vérifier la limitation de bande passante, procédez comme suit :
1. Ouvrez la console de l’interface Application Migration Service.
2. Choisissez Serveurs source, puis sélectionnez le serveur source.
3. Choisissez l'onglet Paramètres de réplication.
3. Si la limitation de bande passante du réseau est activée, assurez-vous que la valeur de limitation est égale ou supérieure à la bande passante requise pour la réplication des données. Pour en savoir plus, consultez la note de la rubrique précédente, Vérifiez le serveur source pour détecter un éventuel pic d'opérations d'écriture.
Vérifications des ressources de la zone de transit
Vérifiez que le port TCP 1500 n'est pas bloqué en entrée.
Assurez-vous que le port TCP 1500 n'est pas bloqué en entrée dans les groupes de sécurité du serveur de réplication.
**Remarque :**vous devez suivre les étapes suivantes dans la console Amazon Elastic Compute Cloud (Amazon EC2).
1. Ouvrez la console Amazon EC2.
2. Sélectionnez le groupe de sécurité associé à l'instance de réplicateur.
3. Vérifiez que le port TCP 1500 entrant est autorisé sur le groupe de sécurité associé.
Vérifiez la métrique NetworkIn CloudWatch.
Si la métrique NetworkIn Amazon CloudWatch pour le serveur de réplication approche de la limite de bande passante, une limitation peut se produire. La limitation entraîne un ralentissement de la vitesse de réplication et un décalage plus important. Envisagez de passer à un type d'instance plus important capable de gérer la bande passante requise.
Vérifiez le débit agrégé et les IOPS des volumes EBS du serveur de réplication
Les performances du serveur de réplication peuvent être limitées si le débit agrégé et les IOPS des volumes Amazon Elastic Block Store (Amazon EBS) dépassent les limites. En cas de limitation, optez pour un type d'instance de serveur de réplication adapté à vos besoins de réplication et préservant les performances sans limitation. Il est recommandé d'utiliser un type d'instance optimisé pour EBS de génération actuelle pour les serveurs de réplication. Sur les instances ne prenant pas en charge le débit optimisé pour EBS, le trafic réseau est en concurrence avec le trafic entre votre instance et vos volumes EBS. Sur les instances optimisées pour EBS, les deux types de trafic sont séparés. Surveillez le réseau de serveurs de réplication et les métriques EBS CloudWatch. Pour en savoir plus, consultez les rubriques suivantes :
Surveillez les métriques pour tous les volumes EBS de réplication
Le décalage et le backlog s'accumulent lorsque la vitesse d'écriture du volume du serveur de réplication ne peut pas correspondre au taux de modification du serveur source. Pour éviter les décalages de réplication, utilisez un type de volume plus rapide avec des IOPS et une bande passante plus élevées. Pour optimiser les performances des volumes EBS, il est recommandé de surveiller les métriques CloudWatch pour chaque volume EBS de réplication.
Vérifiez les volumes EBS créés à partir d'un instantané
Les serveurs de réplication dont les volumes EBS sont créés à partir d'un instantané peuvent avoir augmenté la latence des opérations d'E/S lors du premier accès à chaque bloc. Cette latence peut entraîner une augmentation ou une stagnation du délai jusqu'à ce que le processus de nouvelle numérisation soit terminé. Pour en savoir plus, consultez la rubrique Prenez en compte la baisse des performances lors de l'initialisation de volumes à partir d'instantanés.
Vérifiez le quota d’instantanés dans la région cible.
Assurez-vous que votre compte AWS n'a pas atteint les limites de quota d’instantanés dans la région AWS dans laquelle vous dupliquez les serveurs sources. Utilisez les commandes de l'interface de ligne de commande AWS (AWS CLI) suivantes pour vérifier si vous avez atteint le quota d’instantanés dans la région. Dans l'exemple suivant, remplacez la région par votre région AWS cible :
# 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)"
**Remarque :**si des erreurs interviennent lors de l'exécution des commandes de l'AWS CLI, vérifiez que vous utilisez la version la plus récente de l'AWS CLI.
Informations connexes
Contenus pertinents
- demandé il y a un an
- demandé il y a un an
- demandé il y a un an
- AWS OFFICIELA mis à jour il y a un an