Fehlerbehebung beim cloudübergreifenden Datenzugriff

In diesem Dokument erfahren Sie, wie Sie häufige Probleme bei der Verwendung der Funktion für den cloudübergreifenden Datenzugriff von Borderless Lakehouse beheben.

Daten und Ressourcen sind veraltet oder werden nicht aktualisiert

Lakehouse-Kataloge synchronisieren Metadaten aus einer Remote-Cloud basierend auf einem Aktualisierungsintervall. Die Aktualisierung der Hintergrundmetadaten eines Katalogs kann länger dauern, je mehr Ressourcen vorhanden sind (Freigaben, Schemas, Namespaces, Tabellen). Wenn die vorherige Aktualisierung überläuft, wird die aktuelle Aktualisierung übersprungen. Die nächste Aktualisierung wird jedoch im folgenden Intervall neu geplant.

Wenn abgefragte Daten veraltet sind, läuft die Aktualisierung der Hintergrundmetadaten des Katalogs möglicherweise über oder schlägt fehl. Für Remote-Cloud-Ressourcen gilt dasselbe Verhalten. Wenn Sie eine Ressource in der Remote-Cloud löschen, wird sie erst bei der nächsten erfolgreichen Aktualisierung der Hintergrundmetadaten aus Lakehouse gelöscht.

Prüfen Sie den Status der Aktualisierung der Hintergrundmetadaten für einen föderierten Katalog auf der Lakehouse Google Cloud Konsolenseite oder mit der gcloud CLI:

Zu 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"

Verbindungs- oder Routingprobleme

Wenn bei der Verwendung einer privaten Interconnect-Verbindung Verbindungs- oder Routingprobleme auftreten, prüfen Sie Folgendes:

  • Routenweitergabe prüfen: Prüfen Sie den Cloud Router in Google Cloud um zu bestätigen, dass er die AWS VPC Präfixe gelernt hat. Prüfen Sie Ihre AWS-Routingtabellen, um zu bestätigen, dass sie Routen zurück zu Ihrer Google Cloud VPC enthalten.
  • ILB-Status prüfen:Rufen Sie in der Google Cloud Console Netzwerkdienste > Load-Balancing auf. Prüfen Sie, ob die Back-Ends (NEGs) für Ihren ILB-Back-End-Dienst fehlerfrei sind. Wenn nicht, prüfen Sie die Netzwerkverbindung und die Regeln der AWS-Sicherheitsgruppe.
  • Verbindung von aus testen Google Cloud: Starten Sie eine Test-VM-Instanz in derselben Google Cloud VPC und demselben Subnetz wie der ILB- oder Service Directory-Endpunkt und versuchen Sie, eine Verbindung zu den AWS ENI-IP-Adressen auf Port 443 herzustellen (z. B. mit curl oder telnet).
  • Service Directory-Auflösung:Prüfen Sie, ob das Dienstkonto des Katalogs die Berechtigungen zum Auflösen von Service Directory-Endpunkten hat (roles/servicedirectory.viewer, roles/servicedirectory.pscAuthorizedService).
  • Sicherheitsgruppen und Firewallregeln: Prüfen Sie, ob Google Cloud Firewall regeln und AWS-Sicherheitsgruppen Traffic auf dem TCP-Port 443 zwischen den relevanten IP-Bereichen zulassen.

Aktualisierung des Snowflake-Katalogs schlägt mit Code 16 (Nicht authentifiziert) fehl

Wenn die Aktualisierung der Hintergrundmetadaten für einen Snowflake Horizon Catalog mit dem Status Code 16 (UNAUTHENTICATED) fehlschlägt, prüfen Sie Folgendes:

  • Formatierung der Secret-Nutzlast:Achten Sie darauf, dass das Secret-Token in Secret Manager die erforderliche JSON-Struktur ({"client_secret": "<var>SNOWFLAKE_PAT_TOKEN</var>", "scope": "session:role:<var>SNOWFLAKE_ROLE</var>"}) und nicht den Rohstring des persönlichen Zugriffstokens (Personal Access Token, PAT) enthält.
  • Ablauf und Berechtigungen des Tokens:Achten Sie darauf, dass das Snowflake-PAT gültig ist und der zugehörige Nutzer und die zugehörige Rolle über ausreichende Berechtigungen für den Zugriff auf den Zielkatalog und die Zieldatenbanken verfügen.
  • Netzwerkrichtlinie: Wenn eine Snowflake-Netzwerkrichtlinie konfiguriert ist, achten Sie darauf, dass die Google-IP-Adressbereiche für ausgehenden Traffic aus goog.json auf der Zulassungsliste stehen.