Comment puis-je résoudre les échecs de connectivité des points de terminaison AWS DMS ?

Date de la dernière mise à jour : 08/12/2021

Je ne parviens pas me connecter à mes points de terminaison AWS Database Migration Service (AWS DMS). Pourquoi ma connexion de test échoue-t-elle et comment résoudre ces problèmes de connectivité ?

Brève description

Une fois que vous avez créé vos points de terminaison source et cible AWS DMS, testez la connectivité entre l'instance de réplication AWS DMS et les points de terminaison. Faites-le avant de démarrer la tâche de migration AWS DMS. Il est recommandé de s'assurer que la tâche n'échoue pas en raison de problèmes de connectivité avec le point de terminaison.

Il existe deux types d'erreurs généralement observés lors du test de la connexion entre l'instance de réplication et le point de terminaison source ou cible :

1.    Si l'erreur s'est produite en raison d'un problème de connectivité entre l'instance de réplication et la source ou la cible, des erreurs semblables aux suivantes s'affichent :

Application-Status: 1020912, Application-Message: Failed to connect Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: HYT00 NativeError: 0 Message: [unixODBC][Microsoft][ODBC Driver 13 for SQL Server]Login timeout expired ODBC general error.

Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: 08001 NativeError: 101 Message: [unixODBC]timeout expired ODBC general error.
    
Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider ODBC general error., Application-Detailed-Message: RetCode: SQL_ERROR SqlState: HY000 NativeError: 2005 Message: [unixODBC][MySQL][ODBC 5.3(w) Driver]Unknown MySQL server host 'mysql1.xxxxx.us-east-1.rds.amazonaws.com' (22) ODBC general error.

2.    Si l'erreur s'est produite en raison d'une erreur de base de données native, telle qu'une erreur d’autorisation ou d'authentification de la base de données, des erreurs semblables aux suivantes s'affichent :

Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: 08001 NativeError: 101 Message: [unixODBC]FATAL: password authentication failed for user "dmsuser" ODBC general error.

En fonction du type d'erreur qui s’affiche et de la configuration de votre réseau, consultez la section de résolution appropriée.

Résolution

Résolution des problèmes de connectivité pour les ressources hébergées dans Amazon Web Services (AWS)

Vérifiez que la connectivité peut être établie entre la base de données source ou cible et l'instance de réplication. Selon votre cas d'utilisation et votre infrastructure réseau, connectez votre base de données source ou cible à une instance de réplication dans un sous-réseau public ou un sous-réseau privé. Pour plus d'informations, consultez la section Configuration d'un réseau pour une instance de réplication.

Dans votre instance de réplication, vérifiez que votre configuration inclut les éléments suivants :

  • Une Outbound Rule (Règle de trafic sortant) pour l'adresse IP avec le port de la base de données source ou cible dans le groupe de sécurité. Par défaut, la règle de trafic sortant d'un groupe de sécurité autorise tout trafic. Les groupes de sécurité sont avec état, vous n'avez donc pas besoin de modifier la Inbound Rule (Règle de trafic entrant) par défaut.
  • Une Outbound Rule (Règle de trafic sortant) pour l'adresse IP avec le port de la base de données source ou cible dans la liste ACL réseau. Par défaut, la Outbound Rule (Règle de trafic sortant) de la liste de contrôle d'accès (ACL) réseau autorise tout trafic
  • Une Inbound Rule (Règle de trafic entrant) pour l'adresse IP avec les ports éphémères de la base de données source ou cible dans l'ACL réseau. Par défaut, la Inbound Rule (Règle de trafic entrant) d'une liste ACL réseau autorise tout trafic.

Dans votre base de données source ou cible, vérifiez que votre configuration inclut les éléments suivants :
Remarque : pour rechercher les adresses IP et les CIDR, consultez les étapes permettant de déterminer les adresses IP et le CIDR des groupes de sous-réseaux.

  • Une règle de trafic entrant pour l'adresse IP de l'instance de réplication ou le CIDR du groupe de sous-réseaux de l'instance de réplication avec le port de la base de données source ou cible dans le groupe de sécurité. Les groupes de sécurité sont avec état. Vous n'avez donc pas besoin de modifier la Outbound Rule (Règle de trafic sortant) par rapport à la valeur par défaut.
  • Une Inbound Rule (Règle de trafic entrant) pour l'adresse IP de l'instance de réplication ou le CIDR du groupe de sous-réseaux de l'instance de réplication avec le port de la base de données source ou cible dans la liste ACL réseau. Vérifiez qu'il n'existe aucune règle de refus explicite pour l'adresse IP et le port autorisés.
  • Une Outbound Rule (Règle de trafic sortant) pour l'adresse IP ou le CIDR du groupe de sous-réseaux de l'instance de réplication avec des ports éphémères dans la liste ACL réseau. Par défaut, la Outbound Rule (Règle de trafic sortant) d'une liste ACL réseau autorise tout trafic.
  • Il est recommandé de configurer votre réseau pour autoriser le CIDR du groupe de sous-réseaux de l'instance de réplication. L'adresse IP de l'instance de réplication change lors d'un événement de basculement ou de remplacement d'un hôte.

Pour déterminer les adresses IP et le CIDR du groupe de sous-réseaux afin de configurer les règles de trafic entrant et sortant, utilisez la console AWS DMS ou la CLI.

Utilisation de la console AWS :

  1. Accédez à la console AWS DMS.
  2. Dans le panneau de navigation, choisissez Replication instances (Instances de réplication).
  3. Choisissez le nom de votre instance de réplication.
  4. Sous Details (Détails), notez les champs Public IP address (Adresse IP publique), Private IP address (Adresse IP privée) et Replication subnet group (Groupe de sous-réseaux de réplication) de votre instance de réplication.
  5. Sous Replication subnet group (Groupe de sous-réseaux de réplication), choisissez le lien pour accéder à la page du groupe de sous-réseaux. Notez le nom de chaque sous-réseau du groupe.
  6. Pour vérifier le CIDR de chaque sous-réseau, accédez à la console AWS VPC.
  7. Dans l'onglet Subnets (Sous-réseaux), recherchez les sous-réseaux indiqués à l'étape 5. Pour chaque sous-réseau, notez le CIDR.

Utilisation d’AWS CLI :

Exécutez la commande describe-subnets pour déterminer le CIDR de chaque sous-réseau :

aws ec2 describe-subnets --filters Name=subnet-id,Values="$(aws dms describe-replication-instances --filters "Name=replication-instance-id,Values=<dms replication="" instance="" name="">" --query "ReplicationInstances[*].ReplicationSubnetGroup.Subnets[*].SubnetIdentifier" --output text | sed -e 's/\t/,/g')" --query "Subnets[*].{SubnetId:SubnetId,CidrBlock:CidrBlock}" --output table</dms>

Exécutez la commande describe-replication-instances pour déterminer les adresses IP de l'instance de réplication :

aws dms describe-replication-instances --filters "Name=replication-instance-id,Values=<dms replication="" instance="" name="">" --query "ReplicationInstances[*].{ReplicationInstancePublicIpAddresses:ReplicationInstancePublicIpAddresses,ReplicationInstancePrivateIpAddresses:ReplicationInstancePrivateIpAddresses}" --output table </dms>

Résoudre les problèmes de connectivité pour les ressources sur site

Si votre base de données cible est hébergée sur site, confirmez les points suivants :

  • Vérifiez auprès de votre administrateur réseau que la base de données autorise les connexions entrantes à partir de l'instance de réplication AWS DMS.
  • Vérifiez qu'un pare-feu ne bloque pas la communication vers la base de données source ou cible.
  • Vérifiez que la configuration du DNS est correctement définie. Si vous avez besoin d'une résolution DNS, utilisez Amazon Route 53 Resolver. Pour plus d'informations sur l'utilisation d'un serveur de noms sur site pour résoudre des points de terminaison à l'aide d’Amazon Route 53 Resolver, consultez la section Utilisation de votre propre serveur de noms sur site.

Si les problèmes de connectivité persistent, un dépannage supplémentaire peut être nécessaire. Pour effectuer le dépannage, créez une instance Amazon Elastic Compute Cloud (Amazon EC2) dans le même VPC de l'instance de réplication AWS DMS. Vérifiez que votre instance Amazon EC2 possède les mêmes configurations réseau que l'instance de réplication AWS DMS présentant les problèmes de connectivité. Exécutez les commandes suivantes sur la nouvelle instance EC2 pour dépanner la connectivité réseau :

telnet <database_IP_address_or_DNS> <port_number>
nslookup <domain_name>

Pour database_IP_address_or_DNS, utilisez l'adresse IP ou le nom de domaine de base de données spécifiés pour le point de terminaison source ou cible DMS. Pour port_number, utilisez le numéro de port de la base de données spécifié pour le point de terminaison source ou cible DMS. Pour domain_name, utilisez le nom de domaine de base de données spécifié pour le point de terminaison source ou cible DMS.

Résolution des erreurs de la base de données native

Pour résoudre les erreurs de la base de données native, vérifiez que les configurations de point de terminaison suivantes sont correctement définies :

  • Username (Nom d'utilisateur)
  • Password (Mot de passe)
  • Définissez le ServerName sur DNS ou l'adresse IP de la base de données sur site, ou sur le point de terminaison RDS
  • Port
  • Database name (Nom de base de données)
    Remarque : ne spécifiez aucun nom de base de données pour la source ou la cible MySQL.

Remarque : si l'un de ces champs est spécifié avec AWS Secrets Manager, consultez la section Utilisation de secrets pour accéder aux points de terminaison AWS Database Migration Service.

Pour les erreurs de la base de données native liées à la base de données source ou cible, reportez-vous à la résolution fournie dans la documentation de base de données spécifique. Utilisez le code d'erreur et le message d'erreur sur la console DMS. Pour plus d'informations, consultez les journaux d'erreur, de suivi, d'alerte ou d'autres journaux de la base de données source ou cible.

Pour les erreurs d'accès à la base de données, confirmez les autorisations requises par DMS pour la source ou la cible spécifique.

Pour plus d'informations sur le chiffrement des connexions pour les points de terminaison source et cible à l'aide de Secure Sockets Layer (SSL), consultez la section Utilisation de SSL avec AWS Database Migration Service.