Selfservice-Migration von Looker (Original) zu Looker (Google Cloud Core)

In diesem Dokument werden die technischen Schritte für die Migration Ihrer vorhandenen Looker-Instanz von der Looker (Original)-Umgebung zu Looker (Google Cloud Core) beschrieben.

Looker (Google Cloud Core) ist eine Bereitstellungsumgebung, die eng in die Google Cloud -Plattform eingebunden ist. Looker (Google Cloud Core) wird auf der Google Cloud Infrastruktur gehostet. Sie können es direkt über die Google Cloud Console verwalten und es ist eng in viele der anderen Produkte, Dienste und Funktionen von Google Cloudeingebunden.

Hinweise

  1. Machen Sie sich mit den Google Cloud Grundsätzen und ‑Tools vertraut, indem Sie sich die folgende Dokumentation ansehen:
  2. Wenden Sie sich an Ihren Kundenbetreuer, um mehr über die Migration und die Eignung Ihrer Looker (Original)-Instanz zu erfahren. Wenn Ihre Instanz die Voraussetzungen erfüllt und Sie Ihren bestehenden Looker (Original)-Vertrag auf Looker (Google Cloud Core) aktualisiert haben, können Sie die Schritte in diesem Dokument ausführen, um Ihre Instanz zu migrieren.

  3. Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Google Cloud Projekt zuzuweisen, in dem sich die Looker (Google Cloud Core)-Instanz befindet, um die Berechtigungen zu erhalten, die Sie für die Vorbereitung der Migration benötigen:

    • Looker (Google Cloud Core)-Instanz erstellen: Looker-Administrator (roles/looker.admin).
    • Weisen Sie IAM-Rollen in Ihrem Google Cloud Projekt zu: Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin).
    • Cloud Storage-Bucket erstellen: Storage-Administrator (roles/storage.admin).

    Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

    Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

  4. Wenn Sie die Looker-Instanz (Original) zur Vorbereitung der Migration verwalten möchten, benötigen Sie die Looker-Rolle Administrator für diese Instanz.

  5. Erstellen Sie eine neue „leere“ Looker (Google Cloud Core)-Instanz.

    Achten Sie darauf, dass Sie für Ihre neue Looker (Google Cloud Core)-Instanz die richtige Version, den richtigen Netzwerkverbindungstyp (öffentliche oder private IP-Adresse) und andere Konfigurationsattribute (CMEK, VPC-SC) auswählen, damit sie die erforderlichen Funktionen hat. Einige Funktionen in Looker (Google Cloud Core) hängen von der ausgewählten Version oder dem ausgewählten Netzwerktyp ab.

    Lassen Sie die Instanz „leer“. Fügen Sie keine Daten wie Modelldateien, Nutzer, Verbindungen, Explores, Dashboards oder Ordner hinzu. Während des Imports werden alle Einstellungen oder Inhalte gelöscht und durch Daten aus der Migration ersetzt.

    Die Konfigurationsattribute von Looker (Google Cloud Core), die über die Google Cloud Konsole angegeben werden oder nur während der Instanzerstellung angegeben werden können, werden während der Migration jedoch nicht überschrieben.

Übersicht

Im Großen und Ganzen setzt sich die Migration aus den folgenden Schritten zusammen.

  1. Prüfen Sie, ob Ihre Looker (Original)-Instanz für die Migration bereit ist.
  2. Daten aus Ihrer Looker (Original)-Instanz exportieren
  3. Importieren Sie die Daten in die neue „leere“ Looker (Google Cloud Core)-Instanz.
  4. Einrichtung der Looker (Google Cloud Core)-Instanz abschließen
  5. Looker (Original)-Instanz außer Betrieb nehmen:

In den folgenden Abschnitten finden Sie Details zu den einzelnen Schritten.

Looker-Instanz (Original) für die Migration vorbereiten

Ihre Looker-Instanz (Original) muss die folgenden Voraussetzungen erfüllen, damit sie migriert werden kann:

  • Ihre Looker (Original)-Instanz muss von Google verwaltet werden (d. h. nicht vom Kunden gehostet) und auf Google Cloud oder Amazon Web Services gehostet werden.

  • Für Ihre Looker (Original)-Instanz muss eine Version verwendet werden, die innerhalb einer monatlichen Version der aktuellen Looker (Google Cloud Core)-Version liegt. Die aktuelle Version von Looker (Google Cloud Core) finden Sie in den Looker-Versionshinweisen in der neuesten Bereitstellungsankündigung.

Führen Sie außerdem die folgenden Schritte vor der Migration aus:

  • Es gibt einige Funktionsunterschiede zwischen Looker (Original) und Looker (Google Cloud Core). Sehen Sie sich diese Unterschiede an, um sicherzustellen, dass die Funktionen in Looker (Google Cloud Core) Ihren aktuellen Anforderungen entsprechen.

  • Bei der Migration werden alle Projekte im Produktionsmodus und die darin enthaltenen Modelldateien kopiert, nicht jedoch Projekte im Entwicklermodus, die einzelnen Nutzern gehören. Damit Dateien im Entwicklungsmodus bei der Migration übertragen werden, müssen Sie alle Dateien in allen Projekten im Entwicklungsmodus in Git-Repositories committen, bevor Sie die Migration starten.

  • Looker (Google Cloud Core) unterstützt nur die Authentifizierungsmethoden Google OAuth, SAML und OpenID Connect.

    • Wenn für Ihre Looker (Original)-Instanz eine andere Authentifizierungsmethode verwendet wird (z. B. E-Mail-Adresse und Passwort, LDAP usw.), müssen Sie alle Nutzer in eine von Looker (Google Cloud Core) unterstützte Authentifizierungsmethode umwandeln.
    • Wenn in Ihrer Looker-Instanz (Original) bereits Google OAuth verwendet wird, werden alle Nutzerdatensätze übertragen. Sie müssen jedoch weiterhin manuell IAM-Berechtigungen für die Nutzer im Projekt Ihrer Looker (Google Cloud Core)-Instanz erstellen.
    • Wenn in Ihrer Looker-Instanz (Original) SAML verwendet wird, muss die Einstellung Nutzer zusammenführen mit auf der Seite SAML-Authentifizierung in der Admin-Konsole auf Google oder OIDC festgelegt sein, um einen Fehler zu vermeiden, wenn Sie die SAML-Authentifizierung testen.
    • Wenn für Ihre Looker-Instanz (Original) OIDC verwendet wird, muss die Einstellung Nutzer zusammenführen mit auf der Seite OpenID Connect-Authentifizierung in der Admin-Systemsteuerung auf Google oder SAML festgelegt sein, um einen Fehler zu vermeiden, wenn Sie die OpenID Connect-Authentifizierung testen.
    • Wenn Sie einen externen Identitätsanbieter verwenden, müssen Sie die Callback-URL in Ihrem Identitätsanbieter auf die Looker (Google Cloud Core)-URL aktualisieren, um die Authentifizierung in der neuen Looker (Google Cloud Core)-Instanz zu ermöglichen.
    • Wenn für Ihre Looker (Google Cloud Core)-Instanz SAML oder OpenID Connect als Authentifizierungsmethode verwendet wird, empfiehlt es sich, auch Google OAuth einzurichten, das als Backup-Authentifizierungsmethode für Looker (Google Cloud Core) dient.
    • Wenn Sie eine benutzerdefinierte Domain für Ihre Looker (Google Cloud Core)-Instanz verwenden möchten, richten Sie SAML oder OpenID Connect für die Instanz erst ein, wenn die benutzerdefinierte Domain aktiviert ist.

  • Während der Migration werden zwei Looker-Instanzen – eine Looker-Instanz (Original) und eine Looker (Google Cloud Core)-Instanz – für einen bestimmten Zeitraum parallel ausgeführt. Alle automatischen Aktivitäten, die stattfinden (z. B. Benachrichtigungen und geplante Datenübermittlungen sowie Hintergrundaktivitäten, die auf Backend-Datenbanken zugreifen), können dupliziert werden. Um doppelte Aktivitäten zu vermeiden, löschen Sie automatische Benachrichtigungen und Zeitpläne entweder in der Looker (Original)- oder in der Looker (Google Cloud Core)-Instanz.

Daten aus Ihrer Looker-Instanz (Original) exportieren

Der Export der Daten aus Ihren Looker (Original)-Instanzen erfordert zwei Schritte:

  1. Speicherort für die Migrationsdaten erstellen
  2. Export starten

Speicherort für die Migrationsdaten erstellen

Führen Sie alle folgenden Vorgänge im selben Google Cloud Projekt aus, in dem Sie die Looker (Google Cloud Core)-Instanz erstellt haben.

  1. Erstellen Sie einen neuen Cloud Storage-Bucket (z. B. <bucket-name>).
    • In diesem Bucket werden die Migrationsdaten gespeichert.
    • Folgen Sie der Anleitung auf der Dokumentationsseite Buckets erstellen.
    • Beachten Sie, dass <bucket-name> in allen Google Cloudeindeutig sein muss. Wir empfehlen, dem Bucket-Namen eine eindeutige Kennung voranzustellen, z. B. Ihre Projekt-ID.
  2. Legen Sie einen Namen für einen Ordner im Cloud Storage-Bucket fest (z. B. <folder-name>). Erstellen Sie den Ordner noch nicht. Geben Sie den Ordnernamen bei der Exportanfrage an. Sie wird während des Exportvorgangs automatisch erstellt.
  3. Erstellen Sie einen Schlüsselbund und einen Schlüssel in Cloud KMS (z. B. <kms_keyring_id> und <kms-key-id>).
  4. Erstellen Sie ein neues Dienstkonto speziell für die Migration (z. B. <export-service-account>).

  5. Weisen Sie <export-service-account> die folgenden zwei spezifischen IAM-Rollen zu:

  6. Erstellen Sie einen Dienstkontoschlüssel, der mit <export-service-account> verknüpft ist, und laden Sie die JSON-Schlüsseldatei herunter.

Export anfordern

Nachdem Sie dafür gesorgt haben, dass Ihre Instanz für die Migration bereit ist, eine „leere“ Looker (Google Cloud Core)-Instanz erstellt und einen Speicherort für Migrationsdaten eingerichtet haben, geben Sie die folgenden Informationen auf der Seite Exportieren im Bereich Admin Ihrer Looker (Original)-Instanz ein:

  • Der Name des Cloud Storage-Bucket, den Sie erstellt haben.
  • Der Name des Cloud Storage-Ordners. Ein Ordner mit diesem Namen wird während des Exports automatisch erstellt. Nach Abschluss des Exports werden die Exportdateien in einem untergeordneten Ordner mit Zeitstempel in dem von Ihnen erstellten Cloud Storage-Bucket angezeigt.
  • Der KMS-Schlüsselname.
  • Der JSON-Text, der den Dienstkontoschlüssel enthält.

Nachdem Sie die Informationen auf der Seite Exportieren eingegeben haben, klicken Sie auf Export anfordern, um den Export zu starten.

Der Exportvorgang dauert einige Minuten bis Stunden. Nach Abschluss des Exports werden in Ihrem Cloud Storage-Bucket und -Ordner mehrere Exportdateien (in einem nicht lesbaren Format) angezeigt. Diese Dateien sind die Eingabe für den folgenden Importschritt.

Daten in die neue „leere“ Looker (Google Cloud Core)-Instanz importieren

Nachdem Sie Ihre Instanzdaten exportiert haben, können Sie sie in Ihre Looker (Google Cloud Core)-Instanz importieren.

Folgen Sie der Anleitung auf der Seite Daten aus einem Cloud Storage-Bucket in eine Looker (Google Cloud Core)-Instanz importieren und verweisen Sie mit den Befehlen auf den Bucket und den Ordner, in dem die Exportdateien abgelegt wurden.

Zusammenfassend lässt sich sagen, dass Folgendes erforderlich ist:

  1. Weisen Sie dem Looker-Dienstkonto (nicht dem <export-service-account>) die folgenden Rollen für den Zugriff auf den Bucket und den KMS-Schlüssel zu:
  2. Import über die Google Cloud -Konsole oder die gcloud CLI auslösen

Der Importvorgang dauert einige Minuten bis Stunden. Nach Abschluss wird Ihre Looker (Google Cloud Core)-Instanz mit allen migrierten Daten neu gestartet.

Einrichtung der Looker (Google Cloud Core)-Instanz abschließen

An dieser Stelle können Looker-Administratoren zur Instanz-URL navigieren und sich in der Instanz anmelden, um die Einrichtung abzuschließen.

Beim Migrationsprozess wird so viel wie möglich von der Konfiguration der Looker-Instanz (Original) kopiert. Einige Elemente können jedoch nicht migriert werden oder funktionieren in Looker (Google Cloud Core) etwas anders und müssen angepasst werden.

Einige Artikel, die besondere Aufmerksamkeit erfordern:

Allgemeine Einstellungen (im Bereich Admin von Looker)

Die meisten Optionen für Allgemeine Einstellungen (und andere Einstellungen im Bereich Verwaltung) werden nicht automatisch kopiert, da sie in Looker (Google Cloud Core) in der Regel anders sind oder nicht in derselben Form vorhanden sind. Sie sollten alle Einstellungen sorgfältig prüfen und im Kontext Ihrer ausgewählten Looker (Google Cloud Core)-Konfiguration konfigurieren. Weitere Informationen zu den Einstellungen in Looker (Google Cloud Core) finden Sie auf den Dokumentationsseiten Looker (Google Cloud Core)-Instanz über Looker verwalten und Looker (Google Cloud Core)-Instanz über die Google Cloud Console verwalten.

Nutzer

Looker (Google Cloud Core) unterstützt nur die Authentifizierungsmethoden Google OAuth, SAML und OpenID Connect.

Wenn die Looker-Instanz (Original) ebenfalls für Google-OAuth konfiguriert war, werden die Nutzerdatensätze und ihre Attribute kopiert, sofern sie in beiden Instanzen mit derselben Google-ID und E‑Mail-Adresse verknüpft sind. Ein Projekt-IAM-Administrator muss jedem Nutzer die IAM-Rolle „Looker-Administrator“ oder „Looker-Instanznutzer“ für das Google Cloud Projekt gewähren, in dem sich die Instanz befindet.

Wenn die Looker-Instanz (Original) für SAML oder OpenID Connect konfiguriert war, muss im Feld Nutzer zusammenführen mit für die Authentifizierungsmethode nur Authentifizierungsmethoden angegeben sein, die von Looker (Google Cloud Core) unterstützt werden.

Wenn sich einige Nutzer der Looker-Instanz (Original) über einen Mechanismus authentifiziert haben, der in Looker (Google Cloud Core) nicht unterstützt wird (z. B. LDAP oder E-Mail-Adresse/Passwort), müssen diese Nutzerkonten neu erstellt und in eine unterstützte Authentifizierungsmethode konvertiert werden.

Datenbankverbindungen

Looker (Google Cloud Core) unterstützt eine etwas andere Reihe von Datenbankdialekten als Looker (Original). Alle Konfigurationseigenschaften für Datenbankverbindungen (einschließlich Verbindungsstring und Passwort, falls zutreffend) werden kopiert. Die unterschiedliche Netzwerktopologie in Looker (Google Cloud Core) kann jedoch dazu führen, dass die Datenbankverbindungen nicht sofort funktionieren. Wenn beispielsweise über Firewalls oder Tunnel auf die Datenbanken zugegriffen wird, die für die Looker-Instanz (Original) spezifisch sind, müssen Sie die Firewalls oder Tunnel möglicherweise neu konfigurieren. Sie sollten jede Verbindung testen und sie bei Bedarf neu herstellen.

Datenbankverbindungen mit OAuth

Bei der Migration von Looker (Original) zu Looker (Google Cloud Core) werden OAuth-Zugriffs- oder Aktualisierungstokens für die Datenbankverbindungen einzelner Nutzer zu BigQuery oder Snowflake nicht beibehalten. Nach der Migration werden Looker (Google Cloud Core)-Nutzer aufgefordert, OAuth neu zu authentifizieren, wenn sie ein Explore oder ein Dashboard aufrufen, das auf eine OAuth-Datenbankverbindung verweist. Nutzer können sich auch neu bei ihren Datenbanken authentifizieren, indem sie die Seite Konto aufrufen und für jede Datenbank unter der Überschrift OAuth-Verbindungsanmeldedaten die Option Anmelden auswählen. Alle automatisierten Zeitpläne oder Warnungen, die einem einzelnen Nutzer gehören und auf eine OAuth-Verbindung verweisen, funktionieren erst wieder, wenn sich dieser Nutzer mit seinen OAuth-Anmeldedaten anmeldet.

Verbindungen zu Git-Repositorys

Wenn die Instanz Bare-Git-Repositories verwendet, sollten diese ohne Änderungen funktionieren (kopiert, aber nicht freigegeben). Wenn die Instanz jedoch eine Verbindung zu Remote-Repositories herstellt, müssen diese Verbindungen möglicherweise wie die Datenbankverbindungen überprüft und wieder aktiviert werden.

Andere Netzwerkkonfiguration

Die Looker-Instanz kann andere Arten von Netzwerkverbindungen haben, sowohl eingehende als auch ausgehende (z. B. im Kontext von privater IP, Action Hub, Marketplace, E-Mail usw.). Diese Netzwerkverbindungen müssen ebenfalls verifiziert werden.

URL für den Zugriff auf die Looker (Google Cloud Core)-Instanz

Der Looker (Google Cloud Core)-Instanz wird eine primäre URL zugewiesen, die zufällig generiert wird. Wenn auf die Instanz über eine bestimmte URL zugegriffen werden muss, können Sie eine benutzerdefinierte Domain konfigurieren.

Zeitpläne und Benachrichtigungen

Wenn sowohl die Looker-Instanz (Original) als auch die Looker (Google Cloud Core)-Instanz gleichzeitig aktiv sind, können doppelte geplante Aktionen und Benachrichtigungen generiert und doppelte Hintergrundvorgänge ausgeführt werden, die auf verbundene Datenbanken zugreifen. Diese Aktivitäten sollten in einer der Instanzen so bald wie möglich deaktiviert werden.

Alle automatisierten Zeitpläne oder Warnungen, die einem einzelnen Nutzer gehören und auf die individuelle OAuth-Verbindung dieses Nutzers verweisen, funktionieren erst wieder, wenn sich dieser Nutzer mit seinen OAuth-Anmeldedaten anmeldet.

Wartungsfenster

Im Gegensatz zu Looker (Original) kann für Looker (Google Cloud Core) eine Wartungsrichtlinie angegeben werden.

Elite-Systemaktivität

Daten zu Elite-Systemaktivitäten werden im Rahmen der Migration nicht kopiert. Die Looker (Google Cloud Core)-Instanz wird mit einem neuen Verlauf gestartet.

Benutzerdefinierte Domain

Sie können eine benutzerdefinierte Domain für Ihre Looker (Google Cloud Core)-Instanz erstellen. Sie müssen die DNS-Einträge festlegen, um die Bereitstellung des SSL-Zertifikats zu gewährleisten. Außerdem müssen Sie die Callback-URL in Ihrem Authentifizierungsclient auf die benutzerdefinierte Domain aktualisieren, sobald diese aktiviert und Ihre Authentifizierungsmethode eingerichtet ist. Benutzerdefinierte Domains können für Looker (Google Cloud Core) nicht mit einer looker.com-Domain erstellt werden.

Wenn Sie eine benutzerdefinierte Domain für Ihre Looker (Google Cloud Core)-Instanz mit der benutzerdefinierten URL Ihrer Looker (Original)-Instanz erstellen möchten, sollte die benutzerdefinierte Domain nach Abschluss der Migration und nachdem Sie bestätigt haben, dass die Looker (Google Cloud Core)-Instanz verwendet werden kann, eingerichtet werden. Sobald die benutzerdefinierte Domain aktiviert ist, sehen Ihre Nutzer die Looker (Google Cloud Core)-Instanz und nicht die Looker (Original)-Instanz, wenn sie die Instanz-URL aufrufen.

Richten Sie SAML oder OpenID Connect für die Looker (Google Cloud Core)-Instanz erst ein, wenn die Instanz einsatzbereit ist, die DNS-Einträge aktualisiert wurden und die benutzerdefinierte Domain aktiviert wurde.

Lesezeichen

Wenn Sie in Ihrer Looker-Instanz (Original) eine benutzerdefinierte URL verwenden, die nicht die Domain looker.com nutzt, sollten die Lesezeichen der Nutzer bei der Migration erhalten bleiben, wenn Sie für Ihre Looker (Google Cloud Core)-Instanz eine benutzerdefinierte Domain mit derselben URL wie für Ihre Looker-Instanz (Original) erstellen.

Sobald die benutzerdefinierte Domain aktiviert ist, verweisen Lesezeichen für Looker (Original)-Inhalte wie https://www.yourcustomdomain.com/dashboard/123 auf die Inhalte in der Looker (Google Cloud Core)-Instanz. Hinweis: In den Versionen Enterprise und Embed von Looker (Google Cloud Core) werden in den URLs alphanumerische Inhalts-Slugs anstelle von numerischen Inhalts-IDs verwendet. Eine Lesezeichen-URL mit einer Inhalts-ID wird jedoch weiterhin korrekt zum entsprechenden Inhalt weitergeleitet.

Dieser Vorgang kann nicht mit Looker-URLs (Original) verwendet werden, die die Domain looker.com verwenden.

Diese Liste ist nicht vollständig. Testen Sie alle Aspekte der Instanz, die für Sie am wichtigsten sind, bevor Sie die Migration als abgeschlossen betrachten.

Sobald die Migration abgeschlossen ist und Sie sicher sind, dass Sie keinen weiteren Export benötigen, können Sie die zuvor erstellte <export-service-account> löschen. Dadurch wird der dafür freigegebene JSON-Schlüssel ungültig.

Looker (Original)-Instanz außer Betrieb nehmen

Sobald die migrierte Looker (Google Cloud Core)-Instanz zufriedenstellend funktioniert, können Sie Ihren Nutzern die URL für die Instanz senden und sie anweisen, darauf zuzugreifen und nicht mehr auf die Looker (Original)-Instanz zuzugreifen.

Fehlerbehebung

Die folgenden Abschnitte können Ihnen helfen, Probleme beim Importieren oder Exportieren zu beheben.

Probleme beim Exportieren

Wenn ein Problem beim Export Ihrer Looker-Daten (Original) auftritt, wird auf der Seite Exportieren im Admin-Bereich der Status ERROR angezeigt. Wenn Sie auf den Status ERROR klicken, wird eine Fehlermeldung angezeigt.

Häufige Fehlerquellen:

  • Der Cloud Storage-Bucket, der KMS-Schlüssel oder <export-service-account> ist ungültig.
  • Dem <export-service-account> fehlen die erforderlichen Berechtigungen.

Es ist hilfreich, den Status dieser Objekte zu bestätigen, bevor Sie Ihren Exportantrag einreichen.

Probleme beim Importieren

Wenn der Importvorgang nach vier Stunden (oder möglicherweise länger, wenn die Quellinstanz sehr groß war) nicht abgeschlossen ist oder mit einem Fehler beendet wird, müssen Sie möglicherweise ein Ticket bei Cloud Customer Care erstellen, um das Problem zu beheben. Für diesen Vorgang gibt es relativ wenige Diagnosen, die für Kunden direkt sichtbar sind.

Nächste Schritte