Déboguer la connectivité

MySQL   |  PostgreSQL   |  PostgreSQL vers AlloyDB

Déboguer la connectivité

Vous avez configuré la connectivité entre vos bases de données source et de destination, mais comment savoir qu'elles sont connectées ? Lorsque les communications entre eux échouent, comment pouvez-vous savoir où et pourquoi le problème est survenu ?

Les outils les plus élémentaires sont ping et traceroute.

Ping

Ping effectue un test de base pour déterminer si la destination ("hôte distant") est disponible depuis la source. Ping envoie un paquet ICMP Echo Request à un hôte distant et s'attend à recevoir un ICMP Echo Reply en retour. Si ping échoue, il n'y a pas de route entre la source et la destination. Si elle réussit, cela ne signifie pas pour autant que vos paquets peuvent transiter, mais que, de manière générale, l'hôte distant est accessible.

Si ping peut déterminer si un hôte est actif et en état de répondre, la fiabilité de ce dernier n'est pas garantie. Certains fournisseurs de réseau bloquent ICMP par mesure de sécurité, ce qui peut compliquer le débogage de la connectivité.

Traceroute

La commande Traceroute teste la route complète suivie par les paquets réseau d'un hôte à un autre. Elle montre l'ensemble des étapes ("sauts") parcourues par le paquet tout au long de son acheminement, ainsi que le temps nécessaire à chaque étape. Si le paquet ne parvient pas à destination, traceroute ne se termine pas, mais indique en sortie une série d'astérisques. Dans ce cas, identifiez la dernière adresse IP atteinte avec succès dans l'acheminement. C'est là que la connectivité s'est interrompue.

La commande Traceroute peut expirer. Elle peut également échouer si une passerelle située le long du trajet n'est pas correctement configurée pour transmettre le paquet au saut suivant.

Lorsque traceroute échoue, vous pouvez éventuellement savoir où elle s'est arrêtée. Recherchez la dernière adresse IP indiquée par la sortie de traceroute et faites une recherche sur who owns [IP_ADDRESS] dans un navigateur. Les résultats peuvent afficher ou non le propriétaire de l'adresse, mais cela vaut la peine d'essayer.

mtr

L'outil mtr est une variante de traceroute qui reste active et mise à jour en continu, de la même manière que la commande top pour le suivi des processus locaux.

Localiser votre adresse IP locale

Si vous ne connaissez pas l'adresse locale de votre hôte, exécutez la commande ip -br address show. Sous Linux, cette commande affiche l'interface réseau, l'état de l'interface, l'adresse IP locale et les adresses MAC. Exemple : eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64.

Vous pouvez également exécuter ipconfig ou ifconfig pour afficher l'état de vos interfaces réseau.

Localiser l'adresse IP sortante

Si vous ne connaissez pas l'adresse IP que les bases de données source et de destination utilisent pour communiquer entre elles (l'adresse IP sortante), procédez comme suit:

1. Accédez à la page des clusters AlloyDB dans la console Google Cloud.

   Accéder à la page des clusters AlloyDB

2. Recherchez le cluster associé à la tâche de migration que vous déboguez.

3. L'adresse IP sortante doit apparaître à côté du nom de l'instance principale du cluster.

Ports locaux ouverts

Pour vérifier que votre hôte écoute bien sur les ports que vous pensez, exécutez la commande ss -tunlp4. Cela vous indique quels ports sont ouverts et à l'écoute. Par exemple, si une base de données PostgreSQL est en cours d'exécution, le port 5432 doit être opérationnel et à l'écoute. Pour SSH, vous devriez voir apparaître le port 22.

Ensemble de l'activité sur les ports locaux

Exécutez la commande netstat pour afficher l'ensemble de l'activité des ports locaux. Par exemple, netstat -lt affiche tous les ports actuellement actifs.

Se connecter à l'hôte distant à l'aide de telnet

Pour vérifier que vous pouvez vous connecter à l'hôte distant à l'aide de TCP, exécutez la commande telnet. Telnet tente de se connecter à l'adresse IP et au port que vous lui indiquez.

Par exemple, si votre hôte distant exécute une base de données PostgreSQL, vous devriez pouvoir vous y connecter par telnet sur le port 5432 : telnet 35.193.198.159 5432.

En cas de réussite, les éléments suivants s'affichent :

Trying 35.193.198.159...

Connected to 35.193.198.159. .

En cas d'échec, telnet cesse de répondre jusqu'à ce que vous forciez sa fermeture :

Trying 35.193.198.159...

^C. .

Authentification client

L'authentification du client est contrôlée par un fichier de configuration nommé pg_hba.conf (HBA signifie "authentification basée sur l'hôte").

Assurez-vous que la section des connexions de réplication du fichier pg_hba.conf de la base de données source est mise à jour pour accepter les connexions de la plage d'adresses IP du VPC AlloyDB.

Cloud Logging

Database Migration Service et AlloyDB utilisent Cloud Logging. Consultez la documentation de Cloud Logging pour obtenir des informations complètes et accéder à des exemples de requêtes Cloud SQL.

Afficher les journaux

Vous pouvez afficher les journaux des instances AlloyDB et d'autres projets Google Cloudtels que des instances Cloud VPN ou Compute Engine. Pour afficher les journaux correspondant aux entrées de journal de votre instance AlloyDB:

Console

1. Accéder à l'explorateur de journaux
2. Sélectionnez un projet AlloyDB existant en haut de la page.
3. Dans le générateur de requêtes, ajoutez les éléments suivants :
• Ressource: sélectionnez Base de données AlloyDB. Dans la boîte de dialogue, sélectionnez une instance AlloyDB.
• Noms des journaux: faites défiler la page jusqu'à la section AlloyDB et sélectionnez les fichiers journaux correspondant à votre instance. Par exemple :
  • alloydb.googlapis.com/postgres.log
• Gravité : sélectionnez un niveau de journalisation.
• Période : sélectionnez une valeur prédéfinie ou créez une période personnalisée.

gcloud

Exécutez la commande gcloud logging pour afficher les entrées de journal. Dans l'exemple ci-dessous, remplacez PROJECT_ID. L'option limit est un paramètre facultatif qui indique le nombre maximal d'entrées à renvoyer.

gcloud logging read "projects/[PROJECT_ID]/logs/alloydb.googleapis.com/postgres.log" --limit=10

Dépannage du VPN

Consultez la page Google Cloud Dépannage du VPN Cloud.

Résoudre les erreurs de proxy TCP

La manière dont le proxy TCP est configuré peut également entraîner des erreurs. Pour résoudre une erreur de proxy TCP, consultez les exemples de problèmes suivants et comment les résoudre:

Échec du démarrage de la machine virtuelle (VM)

Le message suivant s'affiche lorsque vous démarrez l'instance de VM dans Compute Engine:

You do not currently have an active account selected.

À essayer

Exécutez l'une des commandes suivantes pour configurer un compte actif:

• Pour obtenir de nouveaux identifiants, exécutez la commande suivante:

  gcloud auth login
  

• Pour sélectionner un compte déjà authentifié, exécutez la commande suivante:

  gcloud config set account ACCOUNT
  

  Remplacez ACCOUNT par le nom du compte que vous souhaitez configurer.

Échec de la connexion à l'instance de base de données source

Le message d'erreur suivant s'affiche lorsque vous testez la tâche de migration:

Failure connecting to the source database. Make sure the connectivity information on the connection profile is correct and the source database is reachable.

À essayer

Suivez la procédure ci-dessous pour identifier l'origine du problème:

1. Vérifiez si la VM hébergeant le conteneur de proxy TCP est en cours d'exécution:

   1. Dans la console, accédez à la page Instances de VM de Compute Engine.

      Accéder à la page Instances de VM

   2. Recherchez la VM créée lors du processus de configuration du proxy. S'il n'est pas listé ou s'il ne s'exécute pas, configurez votre proxy TCP à partir de zéro, puis mettez à jour les paramètres de l'instance source dans la tâche de migration avec l'adresse IP appropriée.

2. Si la VM est en cours d'exécution, vérifiez qu'aucune erreur ne s'est produite lors du téléchargement de l'image du conteneur de proxy TCP:

   1. Sélectionnez la VM créée lors du processus de configuration du proxy TCP. Dans la section Journaux, cliquez sur Port série 1 (console).

   2. Si l'entrée Launching user container 'gcr.io/dms-images/tcp-proxy' ne s'affiche pas dans les journaux, il est possible que votre instance n'ait pas pu extraire l'image de Container Registry. Pour vérifier si c'est le cas, connectez-vous à la VM et essayez manuellement d'extraire l'image de Container Registry à l'aide de la commande suivante:

      docker pull gcr.io/dms-images/tcp-proxy

      Si l'erreur suivante s'affiche: Error response from daemon: Get "https://gcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers), cela signifie que votre VM n'a pas pu se connecter à Container Registry. Si votre VM ne possède qu'une adresse IP privée, vous devez activer l'accès privé à Google sur le sous-réseau auquel l'adresse IP appartient. Sinon, la VM n'aura pas accès aux API Google Enterprise, telles que Container Registry.

3. Vérifiez que le conteneur peut se connecter à l'instance source:

   1. Sélectionnez la VM créée lors du processus de configuration du proxy. Sous Journaux, cliquez sur Cloud Logging.

   2. Si le message suivant s'affiche: Connection refused, please verify that the machine you are using to run the script can connect to the source database at, cela signifie que le conteneur de proxy TCP n'a pas pu se connecter à l'instance de base de données source. Plusieurs raisons peuvent expliquer ce problème:

      • L'adresse IP de l'instance source est incorrecte.
      • Une stratégie de pare-feu refuse les connexions du proxy TCP à l'instance source.
      • L'instance source se trouve dans un réseau cloud privé virtuel (VPC) différent de celui de la VM hébergeant le proxy TCP.

   Vous pouvez déboguer le problème de connectivité à l'aide des tests de connectivité de Google Cloudpour vous assurer qu'il existe une connectivité entre la base de données de destination et la VM hébergeant le proxy TCP:

   1. Dans la console, accédez à la page Tests de connectivité.

      Accéder à Tests de connectivité

   2. Cliquez sur Créer un test de connectivité.

   3. Saisissez un nom pour le test.

   4. Sélectionnez TCP comme protocole.

   5. Sélectionnez Adresse IP dans la liste Point de terminaison source. Saisissez l'adresse IP publique du nouveau proxy TCP si la base de données source est accessible à l'aide d'une adresse IP publique. Sinon, saisissez l'adresse IP privée du proxy TCP.

   6. Sélectionnez Adresse IP dans la liste Point de terminaison de destination, puis saisissez l'adresse IP de la base de données source.

   7. Saisissez le numéro de port utilisé pour vous connecter à la base de données source dans le champ Port de destination.

   8. Cliquez sur Créer.

   Exécutez le test de connectivité et corrigez les problèmes de connectivité qui se produisent. Une fois le problème de connectivité résolu, vérifiez que le proxy TCP peut se connecter à l'instance source:

   1. Accédez à Instances de VM dans Compute Engine.

      Accéder à la page Instances de VM

   2. Sélectionnez la VM créée lors du processus de configuration du proxy. Sous Journaux, cliquez sur Cloud Logging.

   3. Si l'entrée de journal Connection to source DB verified s'affiche, cela signifie que le proxy TCP peut désormais se connecter à l'instance source.

4. Vérifiez que le test de migration ne rencontre pas de problème de connexion.

Échec de la connexion à l'instance de base de données de destination

Si le conteneur proxy TCP peut se connecter à l'instance source, mais que le test de migration échoue toujours en raison de problèmes de connexion, le problème peut être lié à la connectivité entre l'instance de destination et la VM hébergeant le conteneur proxy TCP.

Déboguer le problème

Pour déboguer le problème, vous pouvez utiliser les tests de connectivité de Google Cloudpour vous assurer qu'il existe une connectivité entre la base de données de destination et la VM hébergeant le proxy TCP:

1. Dans la console, accédez à la page Tests de connectivité.

   Accéder à Tests de connectivité

2. Cliquez sur Créer un test de connectivité.

3. Définissez les paramètres suivants pour votre test:

   1. Saisissez un nom pour le test.
   2. Sélectionnez TCP comme protocole.
   3. Sélectionnez Adresse IP dans la liste Point de terminaison source, puis saisissez l'adresse IP du cluster AlloyDB nouvellement créé.
   4. Sélectionnez Adresse IP dans la liste Point de terminaison de destination, puis saisissez l'adresse IP privée du proxy TCP.
   5. Saisissez 5432 dans le champ Port de destination.

4. Cliquez sur Créer.

5. Exécutez le test de connectivité et corrigez les problèmes de connectivité qui se produisent.

Causes possibles

Une règle de pare-feu refuse la communication entre l'instance de destination et la VM proxy TCP.

À essayer

Ajoutez une règle de pare-feu qui permet à l'instance de destination de communiquer avec le proxy TCP via le port 5432.

Causes possibles

Il existe une incohérence de VPC entre l'instance de destination et la VM exécutant le conteneur de proxy TCP.

À essayer

Sélectionnez le même VPC pour l'instance de destination.

Résoudre les problèmes liés aux tunnels SSH inversés

Le tunnel SSH est une méthode permettant de transférer certaines communications sur une connexion SSH. Le tunnel SSH inversé permet de configurer un tunnel SSH, tout en veillant à ce que le réseau de destination soit celui qui lance la connexion du tunnel. Cette option est utile lorsque vous ne souhaitez pas ouvrir de port dans votre propre réseau à des fins de sécurité.

Vous essayez de configurer ce qui suit : AlloyDB DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Bien que Database Migration Service migre les données d'une source vers une destination, vous devez activer la connectivité de la destination vers la source.

Nous partons des hypothèses suivantes:

• Le AlloyDB destination peut accéder au Compute Engine VM bastion.

• Le source network bastion peut accéder au source DB (cela est obtenu en établissant un peering du réseau AlloyDB avec le réseau de la VM Compute Engine).

Vous configurez ensuite un tunnel SSH de source network bastion vers Compute Engine VM bastion, qui achemine toutes les connexions entrantes vers un port sur Compute Engine VM bastion via le tunnel vers source DB.

Chaque maillon du scénario ci-dessus peut être mal configuré et empêcher l'ensemble du flux de fonctionner. Résolvez les problèmes liés à chaque lien, un par un:

source network bastion ---> source DB

1. Connectez-vous à source network bastion à l'aide de SSH ou à partir du terminal s'il s'agit de la machine locale.
2. Testez la connectivité à la base de données source à l'aide de l'une des méthodes suivantes :
   • telnet [source_db_host_or_ip] [source_db_port] : vous devriez voir les chaînes de connexion telnet se terminant par Connected to x.x.x.x.
   • [db_client] -h[source_db_host_or_ip] -P[source_db_port] : l'accès devrait être refusé.

Si cette opération échoue, vous devez vérifier que vous avez activé l'accès de ce bastion à la base de données source.

Compute Engine VM bastion ---> source DB

1. Se connecter à l'Compute Engine VM bastion via SSH (à l'aide de gcloud compute ssh VM_INSTANCE_NAME)
2. Testez la connectivité à la base de données source à l'aide de l'une des méthodes suivantes :
   • telnet 127.0.0.1 [tunnel_port] : vous devriez voir les chaînes de connexion Telnet se terminant par Connected to x.x.x.x.
   • [db_client] -h127.0.0.1 -P[tunnel_port] : l'accès devrait être refusé

Si cela échoue, vous devez vérifier que le tunnel est opérationnel. L'exécution de sudo netstat -tupln affiche tous les processus d'écoute sur cette VM. sshd listening on the tunnel_port devrait s'afficher.

AlloyDB DB ---> source DB

Il est préférable de le tester avec testing the migration job à partir de Database Migration Service. Si l'opération échoue, cela signifie qu'il existe un problème d'appairage ou de routage VPC entre le réseau AlloyDB et le réseau Compute Engine VM bastion.

Le pare-feu du serveur de base de données source doit être configuré pour autoriser l'intégralité de la plage d'adresses IP internes allouée à la connexion de service privée du réseau VPC que l'instance de destination AlloyDB utilisera comme champ privateNetwork dans ses paramètres ipConfiguration.

Pour trouver la plage d'adresses IP internes dans la console, procédez comme suit :

1. Accédez à la page "Réseaux VPC" dans la console Google Cloud .

2. Sélectionnez le réseau VPC que vous souhaitez utiliser.

3. Sélectionnez l'onglet CONNEXION AU SERVICE PRIVÉ.

Vous pouvez également afficher le trafic entre l'instance AlloyDB et l'instance de VM Compute Engine dans la console Cloud Logging du projet Cloud VPN gateway. Dans les journaux de la VM Compute Engine, recherchez le trafic provenant de l'instance AlloyDB. Dans les journaux de l'instance AlloyDB, recherchez le trafic provenant de la VM Compute Engine.