Looker gruppieren

In dieser Anleitung wird die empfohlene Methode zum Erstellen einer geclusterten Looker-Konfiguration erläutert.

Übersicht

Die Looker-Anwendung kann einen einzelnen Knoten oder geclustert ausführen:

  • Die Looker-Anwendung mit einem einzelnen Knoten (Standardkonfiguration) hat alle Dienste, aus denen die Looker-Anwendung besteht, die auf einem einzigen Server ausgeführt wird.
  • Eine geclusterte Looker-Konfiguration ist eine komplexere Konfiguration, die normalerweise Datenbankserver, Load-Balancer und mehrere Server umfasst, auf denen die Looker-Anwendung ausgeführt wird. Jeder Knoten in einer geclusterten Looker-Anwendung ist ein Server, auf dem eine einzelne Looker-Instanz ausgeführt wird.

Es gibt zwei Hauptgründe, warum eine Organisation Looker als Cluster ausführen möchte:

  • Load-Balancing
  • Verbesserte Verfügbarkeit und Failover

Abhängig von den Skalierungsproblemen bietet ein geclusterter Looker möglicherweise keine Lösung. Wenn beispielsweise eine kleine Anzahl großer Abfragen den Systemspeicher belegt, besteht die einzige Lösung darin, den verfügbaren Arbeitsspeicher für den Looker-Prozess zu erhöhen.

Load-Balancing-Alternativen

Erwägen Sie vor dem Load-Balancing von Looker, den Arbeitsspeicher und möglicherweise die CPU-Anzahl eines einzelnen Servers, auf dem Looker ausgeführt wird, zu erhöhen. Looker empfiehlt die Einrichtung einer detaillierten Leistungsüberwachung für die Arbeitsspeicher- und CPU-Auslastung, um sicherzustellen, dass der Looker-Server die richtige Größe für seine Arbeitslast hat.

Große Abfragen benötigen mehr Arbeitsspeicher, um eine bessere Leistung zu erzielen. Clustering kann zu Leistungssteigerungen führen, wenn viele Nutzer kleine Abfragen ausführen.

Bei Konfigurationen mit bis zu 50 Nutzern, die Looker leicht verwenden, empfiehlt Looker, einen einzelnen Server mit einer großen AWS EC2-Instanz auszuführen (M4.large: 8 GB RAM, 2 CPU-Kerne). Bei Konfigurationen mit mehr Nutzern oder vielen aktiven Power-Usern sollten Sie beobachten, ob die CPU-Auslastung zunimmt oder ob Nutzer Verzögerungen in der Anwendung feststellen. Ist dies der Fall, verschieben Sie Looker auf einen größeren Server oder führen Sie eine geclusterte Looker-Konfiguration aus.

Verbesserte Verfügbarkeit/Failover

Wenn Sie Looker in einer Clusterumgebung ausführen, kann die Ausfallzeit bei einem Ausfall minimiert werden. Hochverfügbarkeit ist besonders wichtig, wenn die Looker API in Kerngeschäftssystemen verwendet wird oder wenn Looker in kundenseitige Produkte eingebettet ist.

In einer geclusterten Looker-Konfiguration leitet ein Proxyserver oder Load-Balancer Traffic um, wenn er feststellt, dass ein Knoten ausgefallen ist. Looker verwaltet automatisch Knoten, die den Cluster verlassen und ihm beitreten.

Erforderliche Komponenten

Für eine geclusterte Looker-Konfiguration sind die folgenden Komponenten erforderlich:

  • MySQL-Anwendungsdatenbank
  • Looker-Knoten (Server, auf denen der Looker-Java-Prozess ausgeführt wird)
  • Load-Balancer
  • Freigegebenes Dateisystem
  • Richtige Version der JAR-Dateien der Looker-Anwendung

Das folgende Diagramm veranschaulicht, wie die Komponenten interagieren:

MySQL-Anwendungsdatenbank

Looker verwendet eine Anwendungsdatenbank, die oft als interne Datenbank bezeichnet wird, um Anwendungsdaten zu speichern. Wenn Looker als Anwendung mit einem einzelnen Knoten ausgeführt wird, verwendet es normalerweise eine speicherinterne HyperSQL-Datenbank.

In einer geclusterten Looker-Konfiguration muss jede Looker-Instanz jedes Knotens auf eine gemeinsame Transaktionsdatenbank (die freigegebene Anwendung oder interne Datenbank) verweisen. Die Anwendungsdatenbank für die geclusterten Looker wird so unterstützt:

  • Für die Anwendungsdatenbank für geclusterte Looker-Instanzen wird nur MySQL unterstützt. Amazon Aurora und MariaDB werden nicht unterstützt.
  • MySQL-Versionen ab 5.7 und 8.0 werden unterstützt.
  • Geclusterte Datenbanken wie Galera werden nicht unterstützt.

Es wird empfohlen, eine Lesereplikatdatenbank zu verwenden, um Leistung und Redundanz zu verbessern. Ihre Lesereplikatdatenbank muss keine MySQL-Datenbank sein.

Looker verwaltet die Wartung und Sicherung der Datenbank nicht. Da die Datenbank jedoch fast alle Konfigurationsdaten der Looker-Anwendung hostet, sollte sie als Hochverfügbarkeitsdatenbank bereitgestellt und mindestens täglich gesichert werden.

Looker-Knoten

Jeder Knoten ist ein Server, auf dem der Looker-Java-Prozess ausgeführt wird. Die Server im Looker-Cluster müssen miteinander und mit der Looker-Anwendungsdatenbank kommunizieren können. Die Standardports sind auf dieser Seite unter Ports für die Kommunikation zwischen den Knoten öffnen aufgeführt.

Load-Balancer

Zum Ausgleichen der Last oder der Weiterleitungsanfragen an verfügbare Knoten ist ein Load-Balancer oder Proxyserver (z. B. NGINX oder AWS ELB) erforderlich, um Traffic an jeden Looker-Knoten weiterzuleiten. Der Load-Balancer verarbeitet Systemdiagnosen. Bei einem Knotenfehler muss der Load-Balancer so konfiguriert werden, dass der Traffic an die verbleibenden fehlerfreien Knoten weitergeleitet wird.

Achten Sie bei der Auswahl und Konfiguration des Load-Balancers darauf, dass er nur als Ebene 4 konfiguriert werden kann. Ein Beispiel hierfür ist der klassische ELB von Amazon. Außerdem sollte der Load-Balancer ein langes Zeitlimit von 3.600 Sekunden haben, damit Abfragen nicht beendet werden.

Freigegebenes Dateisystem

Sie müssen ein POSIX-konformes freigegebenes Dateisystem verwenden, z. B. NFS, AWS EFS, Gluster, BeeGFS, Lustre oder viele andere. Looker verwendet das freigegebene Dateisystem als Repository für verschiedene Informationen, die von allen Knoten im Cluster verwendet werden.

Für die Installation von Anwendungen und Tools aus dem Looker Marketplace ist ein freigegebenes (Netzwerk-)Dateisystem erforderlich.

Looker-Anwendung (ausführbare JAR-Datei)

Sie müssen die JAR-Datei der Looker-Anwendung verwenden, die Looker 3.56 oder höher ist.

Ab Looker 6.18 wurde die Looker-JAR-Datei in zwei separate JAR-Dateien aufgeteilt: die Looker-Kern-JAR-Datei und eine Looker-JAR-Datei für Abhängigkeiten. Wenn Sie Looker 6.18 oder höher installieren oder aktualisieren, müssen Sie beide JAR-Dateien herunterladen.

Looker empfiehlt dringend, auf jedem Knoten in einem Cluster dieselbe Looker-Release- und -Patch-Version auszuführen, wie unter Looker auf den Knoten auf dieser Seite starten erläutert.

Cluster einrichten

Die folgenden Aufgaben sind erforderlich:

  1. Looker installieren
  2. MySQL-Anwendungsdatenbank einrichten
  3. Freigegebenes Dateisystem einrichten
  4. SSH-Schlüssel-Repository freigeben (je nach Ihrer Situation)
  5. Ports für die Kommunikation zwischen den Knoten öffnen
  6. Looker auf den Knoten starten

Looker installieren

Prüfen Sie, ob Looker auf jedem Knoten installiert ist. Verwenden Sie dazu die JAR-Dateien für die Looker-Anwendung und die Anleitung auf der Dokumentationsseite Vom Kunden gehostete Installationsschritte.

MySQL-Anwendungsdatenbank einrichten

Für eine geclusterte Looker-Konfiguration muss die Anwendungsdatenbank eine MySQL-Datenbank sein. Wenn Sie eine nicht gruppierte Looker-Instanz haben, die HyperSQL für die Anwendungsdatenbank verwendet, müssen Sie die Anwendungsdaten aus den HyperSQL-Daten in die neue freigegebene MySQL-Anwendungsdatenbank migrieren.

Sichern Sie unbedingt das Looker-Verzeichnis. Der Migrationsprozess kann nur von einer HyperSQL-Datenbank zu einer MySQL-Datenbank und nicht umgekehrt ausgeführt werden.

Informationen zum Sichern von Looker und zum Migrieren der Anwendungsdatenbank von HyperSQL zu MySQL finden Sie auf der Dokumentationsseite Zu MySQL migrieren.

Freigegebenes Dateisystem einrichten

Nur bestimmte Dateitypen – Modelldateien, Bereitstellungsschlüssel, Plug-ins und möglicherweise Manifestdateien von Anwendungen – gehören zum freigegebenen Dateisystem. So richten Sie das freigegebene Dateisystem ein:

  1. Prüfen Sie auf dem Server, auf dem das freigegebene Dateisystem gespeichert wird, ob Sie Zugriff auf ein anderes Konto mit der Berechtigung su für das Looker-Nutzerkonto haben.
  2. Melden Sie sich auf dem Server für das freigegebene Dateisystem im Looker-Nutzerkonto an.
  3. Schließen Sie die Looker-Konfiguration, wenn Looker ausgeführt wird.
  4. Wenn Sie zuvor Cluster mit Linux-Skripts erstellt haben, beenden Sie diese Skripts, entfernen Sie sie aus Cron und löschen Sie sie.
  5. Netzwerkfreigabe erstellen und auf jedem Knoten im Cluster bereitstellen Achten Sie darauf, dass es für die automatische Bereitstellung auf jedem Knoten konfiguriert ist und der Looker-Nutzer Lese- und Schreibzugriff darauf hat. Im folgenden Beispiel hat die Netzwerkfreigabe den Namen /mnt/looker-share.

  6. Verschieben Sie auf einem Knoten Ihre Bereitstellungsschlüssel, Plug-ins und die Verzeichnisse looker/models und looker/models-user-*, in denen Ihre Modelldateien gespeichert sind, in Ihre Netzwerkfreigabe. Beispiel:

    mv looker/models /mnt/looker-share/
mv looker/models-user-* /mnt/looker-share/

  7. Fügen Sie für jeden Knoten die Einstellung --shared-storage-dir zu LOOKERARGS hinzu. Geben Sie die Netzwerkfreigabe wie in diesem Beispiel an:

    --shared-storage-dir /mnt/looker-share

    LOOKERARGS sollte zu $HOME/looker/lookerstart.cfg hinzugefügt werden, damit die Einstellungen nicht von Aktualisierungen beeinflusst werden. Wenn Ihre LOOKERARGS nicht in dieser Datei aufgeführt ist, wurde sie möglicherweise direkt dem $HOME/looker/looker-Shell-Skript hinzugefügt.

    Jeder Knoten im Cluster muss in ein eindeutiges /log-Verzeichnis oder zumindest eine eindeutige Logdatei schreiben.

SSH-Schlüssel-Repository freigeben

  • Sie erstellen einen freigegebenen Dateisystemcluster aus einer vorhandenen Looker-Konfiguration und
  • Sie haben Projekte, die in Looker 4.6 oder früher erstellt wurden.

Für das folgende Verfahren müssen Sie die $HOME/.ssh directory des Looker-Nutzers ändern. Dies kann die Anmeldung erschweren und Probleme beheben, wenn die Konfiguration Fehler enthält. Prüfen Sie, ob Sie Zugriff auf ein anderes Konto haben, mit dem Sie eine su-Verknüpfung zum Looker-Nutzerkonto herstellen können, bevor Sie diese Schritte ausführen.

Richten Sie das SSH-Schlüssel-Repository ein, das freigegeben werden soll:

  1. Erstellen Sie auf dem freigegebenen Dateiserver ein Verzeichnis namens ssh-share. Beispiel: /mnt/looker-share/ssh-share

    Achten Sie darauf, dass das Verzeichnis ssh-share dem Looker-Nutzer gehört und die Berechtigungen 700 sind. Achten Sie außerdem darauf, dass Verzeichnisse über dem Verzeichnis ssh-share (wie /mnt und /mnt/looker-share) nicht von der Welt beschreibbar oder beschreibbar sind.

  2. Kopieren Sie auf einem Knoten den Inhalt von $HOME/.ssh in das neue Verzeichnis ssh-share. Beispiel:

    cp $HOME/.ssh/* /mnt/looker-share/ssh-share

  3. Erstellen Sie für jeden Knoten eine Sicherung der vorhandenen SSH-Datei und erstellen Sie einen Symlink zum Verzeichnis ssh-share. Beispiel:

    cd $HOME
mv .ssh .ssh_bak
ln -s /mnt/looker-share/ssh-share .ssh

    Führen Sie diesen Schritt für jeden Knoten aus.

Ports für die Kommunikation öffnen

Geclusterte Looker-Knoten kommunizieren über HTTPS mit selbst signierten Zertifikaten und einem zusätzlichen Authentifizierungsschema, das auf rotierenden Secrets in der Anwendungsdatenbank basiert.

Die Standardports, die zwischen Clusterknoten geöffnet sein müssen, sind 1551 und 61616. Diese Ports können mit den hier aufgeführten Start-Flags konfiguriert werden. Wir empfehlen dringend, den Netzwerkzugriff auf diese Ports einzuschränken, um Traffic nur zwischen den Clusterhosts zuzulassen.

Looker auf den Knoten starten

Starten Sie den Server auf jedem Knoten mit den erforderlichen Start-Flags neu.

Jeder Knoten in einem Cluster muss dieselbe Release- und Patchversion ausführen.

Verfügbare Start-Flags

Die folgende Tabelle enthält verfügbare Start-Flags, einschließlich der Flags, die zum Starten oder Zusammenführen eines Clusters erforderlich sind:

Flag Erforderlich/Optional? Werte Zweck
--clustered Ja Fügen Sie ein Flag hinzu, um anzugeben, dass dieser Knoten im Clustermodus ausgeführt wird.
-H oder --hostname Ja 10.10.10.10 Der Hostname, über den andere Knoten den Knoten kontaktieren, z. B. die IP-Adresse des Knotens oder der Systemhostname. Muss sich von den Hostnamen aller anderen Knoten im Cluster unterscheiden.
-n Nein 1551 Der Port für die knotenübergreifende Kommunikation. Der Standardwert ist 1551. Alle Knoten müssen für die Kommunikation zwischen Knoten dieselbe Portnummer verwenden.
-q Nein 61616 Der Port für clusterübergreifende Ereignisse in der Warteschlange. Der Standardwert ist 61616.
-d Ja /path/to/looker-db.yml Der Pfad zur Datei, die die Anmeldedaten für die Looker-Anwendungsdatenbank enthält.
--shared-storage-dir Ja /path/to/mounted/shared/storage Die Option muss auf die frühere Einrichtung des freigegebenen Verzeichnisses verweisen, in dem sich die Verzeichnisse looker/model und looker/models-user-* befinden.

Das Start-Flag --clustered sollte keinen Wert enthalten.

Beispiel für LOOKERARGS und Angabe von Datenbankanmeldedaten

Legen Sie die Looker-Start-Flags in einer lookerstart.cfg-Datei ab, die sich im selben Verzeichnis wie die Looker-JAR-Dateien befindet.

Beispielsweise können Sie Looker mitteilen:

  • So verwenden Sie die Datei mit dem Namen looker-db.yml als Datenbankanmeldedaten:
  • dass es ein geclusterter Knoten ist und
  • dass die anderen Knoten des Clusters diesen Host über die IP-Adresse 10.10.10.10 kontaktieren sollen.

Geben Sie dazu Folgendes an:

LOOKERARGS="-d looker-db.yml --clustered -H 10.10.10.10"

Achten Sie darauf, die richtige IP-Adresse für Ihren Knoten anzugeben.

Die Datei looker-db.yml enthält die Datenbankanmeldedaten, z. B.:

host: your.db.hostname.com
username: db_user
database: looker
dialect: mysql
port: 3306
password: secretPassword

Wenn für Ihre MySQL-Datenbank eine SSL-Verbindung erforderlich ist, erfordert die Datei looker-db.yml außerdem Folgendes:

ssl: true

Beachten Sie beim Speichern von Anmeldedaten in einer Datei die Best Practices für die Sicherheit. Idealerweise sollten Sie die Berechtigungen für die Datei looker-db.yml auf 600 festlegen. Diese gehören dem Linux-Konto, unter dem die Looker-Anwendung ausgeführt wird. Diese Datei sollte nie in ein Git-Repository eingecheckt werden.

Wenn Sie die Konfiguration nicht in der Datei looker-db.yml auf dem Laufwerk speichern möchten, können Sie die Umgebungsvariable LOOKER_DB so konfigurieren, dass sie eine Liste mit Schlüsseln/Werten für jede Zeile in der Datei looker-db.yml enthält. Beispiel:

export LOOKER_DB="dialect=mysql&host=localhost&username=root&password=&database=looker&port=3306"

Git-SSH-Bereitstellungsschlüssel finden

Wo Looker die Git-SSH-Bereitstellungsschlüssel speichert, hängt vom Release ab, in dem das Projekt erstellt wurde:

  • Bei Projekten, die vor Looker 4.8 erstellt wurden, werden die Bereitstellungsschlüssel im nativen SSH-Verzeichnis des Servers, ~/.ssh, gespeichert.
  • Bei Projekten, die in Looker 4.8 oder höher erstellt wurden, werden die Bereitstellungsschlüssel in einem von Looker gesteuerten Verzeichnis ~/looker/deploy_keys/PROJECT_NAME gespeichert.

Looker-Cluster ändern

Nachdem Sie einen Looker-Cluster erstellt haben, können Sie Knoten hinzufügen oder entfernen, ohne Änderungen an den anderen geclusterten Knoten vorzunehmen.

Cluster auf einen neuen Looker-Release aktualisieren

Aktualisierungen können Schemaänderungen an der internen Datenbank von Looker beinhalten, die mit früheren Looker-Versionen nicht kompatibel sind. Es gibt zwei Methoden, um Looker zu aktualisieren.

Sicherere Methode

  1. Erstellen Sie eine Sicherung der Anwendungsdatenbank.
  2. Alle Knoten des Clusters anhalten.
  3. Ersetzen Sie die JAR-Dateien auf jedem Server.
  4. Starten Sie die einzelnen Knoten einzeln.

Schnellere Methode

Mit dieser Methode wird die Ausfallzeit verringert. Alle Änderungen, die zwischen dem Erstellen des Replikats und dem Verweisen des Proxyservers auf die neuen Knoten vorgenommen wurden, gehen jedoch verloren. Wenn ein Nutzer beispielsweise während der Umstellung Nutzer hinzufügt oder Looks erstellt, werden diese Änderungen möglicherweise nicht in der neuen Anwendungsdatenbank erfasst.

So gehts:

  1. Erstellen Sie ein Replikat der Anwendungsdatenbank von Looker.
  2. Starten Sie einen neuen Cluster, der auf das Replikat verweist.
  3. Verweisen Sie den Proxyserver oder Load-Balancer auf die neuen Knoten. Danach können Sie die alten Knoten beenden.