Résoudre les problèmes d'accès aux données multicloud

Ce document explique comment résoudre les problèmes courants liés à l'utilisation de la fonctionnalité d'accès aux données multicloud de Lakehouse sans limites.

Les données et les ressources sont obsolètes ou ne sont pas mises à jour

Les catalogues fédérés Lakehouse synchronisent les métadonnées d'un cloud distant en fonction d'un intervalle d'actualisation. L'actualisation des métadonnées en arrière-plan d'un catalogue peut prendre plus de temps en fonction du nombre de ressources (partages, schémas, espaces de noms, tables). Si l'actualisation précédente dépasse le délai imparti, l'actualisation en cours est ignorée, mais la suivante est reprogrammée à l'intervalle suivant.

Si les données interrogées semblent obsolètes, il est possible que l'actualisation des métadonnées en arrière-plan du catalogue dépasse le délai imparti ou échoue. Les ressources cloud distantes sont également soumises au même comportement. Si vous supprimez une ressource dans le cloud distant, elle ne sera supprimée de Lakehouse que lors de la prochaine actualisation réussie des métadonnées en arrière-plan.

Vérifiez l'état de l'actualisation des métadonnées en arrière-plan d'un catalogue fédéré sur la page de la console Lakehouse Google Cloud ou en exécutant gcloud CLI :

Accéder à Lakehouse

gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID"

gcloud alpha biglake delta-sharing catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID"

Problèmes de connectivité ou de routage

Si vous rencontrez des problèmes de connectivité ou de routage lorsque vous utilisez une interconnexion privée, vérifiez les points suivants :

  • Vérifiez la propagation des routes : vérifiez le routeur Cloud Router dans Google Cloud pour vous assurer qu'il a appris les préfixes VPC AWS. Vérifiez vos tables de routage AWS pour vous assurer qu'elles comportent des routes vers votre Google Cloud VPC.
  • Vérifiez l'état de l'ILB : dans la Google Cloud console, accédez à Services réseau > Équilibrage de charge. Vérifiez si les backends (NEG) de votre service de backend ILB sont opérationnels. Si ce n'est pas le cas, vérifiez la connectivité réseau et les règles du groupe de sécurité AWS.
  • Testez la connectivité à partir de Google Cloud: lancez une instance de VM de test dans le même Google Cloud VPC et le même sous-réseau que le point de terminaison ILB ou Annuaire des services puis essayez de vous connecter aux adresses IP ENI AWS sur le port 443 (par exemple, à l'aide de curl ou telnet).
  • Résolution de l'Annuaire des services : vérifiez que le compte de service du catalogue dispose des autorisations nécessaires pour résoudre les points de terminaison de l'Annuaire des services (roles/servicedirectory.viewer, roles/servicedirectory.pscAuthorizedService).
  • Groupes de sécurité et règles de pare-feu : vérifiez que Google Cloud les règles de pare-feu et les groupes de sécurité AWS autorisent le trafic sur le port TCP 443entre les plages d'adresses IP concernées.

L'actualisation du catalogue Snowflake échoue avec le code 16 (non authentifié)

Si l'actualisation des métadonnées en arrière-plan d'un catalogue Snowflake Horizon échoue avec l'état Code 16 (UNAUTHENTICATED), vérifiez les points suivants :

  • Mise en forme de la charge utile du secret : assurez-vous que le jeton secret dans Secret Manager contient la structure JSON requise ({"client_secret": "<var>SNOWFLAKE_PAT_TOKEN</var>", "scope": "session:role:<var>SNOWFLAKE_ROLE</var>"}) plutôt que la chaîne brute du jeton d'accès personnel (PAT).
  • Expiration et autorisations du jeton : assurez-vous que le PAT Snowflake est valide et que l'utilisateur et le rôle associés disposent des privilèges suffisants pour accéder au catalogue et aux bases de données cibles.
  • Règle de réseau : si une règle de réseau Snowflake est configurée, assurez-vous que les plages d'adresses IP de sortie de Google provenant de goog.json sont ajoutées à la liste d'autorisation.