Looker clustern

In dieser Anleitung wird die empfohlene Methode zum Erstellen einer geclusterten Looker-Konfiguration für vom Kunden gehostete Instanzen beschrieben.

Übersicht

Von Kunden gehostete Looker-Bereitstellungen können als Einzelknoten oder als Cluster ausgeführt werden:

• Bei einer Looker-Anwendung mit einem Knoten, der Standardkonfiguration, werden alle Dienste, aus denen die Looker-Anwendung besteht, auf einem einzigen Server ausgeführt.
• Eine geclusterte Looker-Konfiguration ist komplexer und umfasst in der Regel Datenbankserver, Load-Balancer und mehrere Server, 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

Je nach Skalierungsproblem ist ein geclusterter Looker möglicherweise nicht die richtige Lösung. Wenn beispielsweise eine kleine Anzahl großer Abfragen den Systemarbeitsspeicher aufbraucht, besteht die einzige Lösung darin, den verfügbaren Arbeitsspeicher für den Looker-Prozess zu erhöhen.

Alternativen für das Load-Balancing

Bevor Sie Looker per Load-Balancing ausgleichen, sollten Sie den Arbeitsspeicher und möglicherweise die CPU-Anzahl eines einzelnen Servers, auf dem Looker ausgeführt wird, erhöhen. Looker empfiehlt, ein detailliertes Leistungsmonitoring für die Speicher- und CPU-Auslastung einzurichten, um sicherzustellen, dass der Looker-Server für seine Arbeitslast richtig dimensioniert ist.

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

Für Konfigurationen mit bis zu 50 Nutzern, die Looker nur gelegentlich verwenden, empfiehlt Looker die Ausführung eines einzelnen Servers, der einer großen AWS EC2-Instanz entspricht (M4.large: 8 GB RAM, 2 CPU-Kerne). Bei Konfigurationen mit mehr Nutzern oder vielen aktiven Power-Usern sollten Sie darauf achten, ob die CPU-Auslastung ansteigt oder Nutzer eine Verlangsamung der Anwendung bemerken. Wenn ja, migrieren 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, können Sie Ausfallzeiten im Falle eines Ausfalls reduzieren. Hohe Verfügbarkeit ist besonders wichtig, wenn die Looker API in wichtigen Geschäftssystemen verwendet wird oder wenn Looker in kundenorientierte Produkte eingebettet ist.

In einer geclusterten Looker-Konfiguration leitet ein Proxyserver oder Load-Balancer den Traffic um, wenn er feststellt, dass ein Knoten ausgefallen ist. Looker verarbeitet automatisch Knoten, die den Cluster verlassen oder 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
• Die richtige Version der JAR-Dateien der Looker-Anwendung

Das folgende Diagramm veranschaulicht, wie die Komponenten interagieren. Ein Load Balancer verteilt den Netzwerk-Traffic auf die Looker-Knoten in einem Cluster. Die Knoten kommunizieren jeweils mit einer gemeinsamen MySQL-Anwendungsdatenbank, einem gemeinsamen Speicherverzeichnis und den Git-Servern für jedes LookML-Projekt.

MySQL-Anwendungsdatenbank

In Looker wird eine Anwendungsdatenbank (oft als interne Datenbank bezeichnet) zum Speichern von Anwendungsdaten verwendet. Wenn Looker als Einzelknotenanwendung ausgeführt wird, wird normalerweise eine speicherresidente HyperSQL-Datenbank verwendet.

In einer geclusterten Looker-Konfiguration muss die Looker-Instanz jedes Knotens auf eine gemeinsam genutzte Transaktionsdatenbank (die gemeinsam genutzte Anwendungs- oder interne Datenbank) verweisen. Die Unterstützung für die Anwendungsdatenbank für geclusterte Looker-Instanzen ist wie folgt:

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

Hinweis :Eine Lesereplikat-Datenbank wird empfohlen, um Leistung und Redundanz zu verbessern. Ihre Lesereplikatdatenbank muss keine MySQL-Datenbank sein.

Looker verwaltet die Wartung und Sicherung dieser Datenbank nicht. Da in der Datenbank jedoch fast alle Konfigurationsdaten der Looker-Anwendung gespeichert sind, sollte sie als Datenbank mit hoher Verfügbarkeit 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 sich gegenseitig und die Looker-Anwendungsdatenbank erreichen können. Die Standardports sind auf dieser Seite unter Ports für die Kommunikation der Knoten öffnen aufgeführt.

Load-Balancer

Um die Last auszugleichen oder Anfragen an verfügbare Knoten weiterzuleiten, ist ein Load Balancer oder Proxyserver (z. B. NGINX oder AWS ELB) erforderlich, um Traffic an jeden Looker-Knoten weiterzuleiten. Der Load-Balancer führt Systemdiagnosen durch. Bei einem Knotenausfall muss der Load Balancer so konfiguriert sein, dass der Traffic an die verbleibenden fehlerfreien Knoten weitergeleitet wird.

Achten Sie beim Auswählen und Konfigurieren des Load-Balancers darauf, dass er so konfiguriert werden kann, dass er nur auf Layer 4 arbeitet. Ein Beispiel dafür ist der Amazon Classic ELB. Außerdem sollte der Load Balancer ein langes Zeitlimit (3.600 Sekunden) haben, damit Abfragen nicht beendet werden.

Freigegebenes Dateisystem

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

Hinweis :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 eine JAR-Datei für die Looker-Anwendung verwenden, die Looker 3.56 oder höher ist.

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

Looker empfiehlt dringend, dass auf jedem Knoten in einem Cluster dieselbe Looker-Release- und Patchversion ausgeführt wird, wie auf dieser Seite unter Looker auf den Knoten starten beschrieben.

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 Situation)
5. Ports für die Kommunikation der Knoten öffnen
6. Looker auf den Knoten starten

Looker installieren

Achten Sie darauf, dass Looker auf jedem Knoten installiert ist. Verwenden Sie dazu die JAR-Dateien der Looker-Anwendung und die Anleitung auf der Dokumentationsseite Installationsschritte für selbst gehostete Installationen.

MySQL-Anwendungsdatenbank einrichten

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

Hinweis :Sichern Sie Ihr Looker-Verzeichnis. Die Migration kann nur von einer HyperSQL- zu einer MySQL-Datenbank erfolgen, nicht umgekehrt.

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 wie Modelldateien, Bereitstellungsschlüssel, Plug-ins und möglicherweise Anwendungsmanifestdateien gehören in das freigegebene 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 haben, das su für das Looker-Nutzerkonto ausführen kann.
2. Melden Sie sich auf dem Server für das freigegebene Dateisystem im Looker-Nutzerkonto an.
3. Wenn Looker ausgeführt wird, beenden Sie die Looker-Konfiguration.
4. Wenn Sie zuvor Clustering mit inotify-Linux-Skripts verwendet haben, beenden Sie diese Skripts, entfernen Sie sie aus cron und löschen Sie sie.
5. Erstellen Sie eine Netzwerkfreigabe und stellen Sie sie auf jedem Knoten im Cluster bereit. Achten Sie darauf, dass das Laufwerk auf jedem Knoten automatisch gemountet wird und der Looker-Nutzer Lese- und Schreibzugriff darauf hat. Im folgenden Beispiel heißt die Netzwerkfreigabe /mnt/looker-share.

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

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

   Hinweis :Ihre Bereitstellungsschlüssel müssen in den freigegebenen Speicher und auf jeden Knoten im Cluster kopiert werden.

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

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

   LOOKERARGS sollte zu $HOME/looker/lookerstart.cfg hinzugefügt werden, damit die Einstellungen nicht von Updates betroffen sind. Wenn Ihre LOOKERARGS nicht in dieser Datei aufgeführt sind, hat sie möglicherweise jemand direkt dem $HOME/looker/looker-Shell-Script hinzugefügt.

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

SSH-Schlüssel-Repository freigeben

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

Hinweis :Für das folgende Verfahren muss das $HOME/.ssh-Verzeichnis des Looker-Nutzers geändert werden. Das kann es erschweren, sich anzumelden und Fehler in der Konfiguration zu beheben. Bevor Sie diese Schritte ausführen, müssen Sie Zugriff auf ein anderes Konto haben, das su mit dem Looker-Nutzerkonto verknüpft ist.

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

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

   Achten Sie darauf, dass das Verzeichnis ssh-share dem Looker-Nutzer gehört und die Berechtigungen auf 700 festgelegt sind. Achten Sie außerdem darauf, dass Verzeichnisse über dem Verzeichnis ssh-share (z. B. /mnt und /mnt/looker-share) nicht für alle oder für Gruppen 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 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 der Knoten öffnen

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

Die Standardports, die zwischen Clusternknoten 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, damit nur Traffic zwischen den Clusterhosts möglich ist.

Looker auf den Knoten starten

Starten Sie den Server auf jedem Knoten mit den erforderlichen Startflags neu.

Hinweis :Auf jedem Knoten in einem Cluster muss dieselbe Looker-Release- und Patch-Version ausgeführt werden.

Verfügbare Start-up-Flags

In der folgenden Tabelle sind die verfügbaren Start-Flags aufgeführt, einschließlich der Flags, die zum Starten oder Beitreten 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, den andere Knoten verwenden, um diesen Knoten zu kontaktieren, z. B. die IP-Adresse des Knotens oder sein Systemhostname. Muss sich von den Hostnamen aller anderen Knoten im Cluster unterscheiden.
-n	Nein	1551	Der Port für die Kommunikation zwischen Knoten. Der Standardwert ist 1551. Alle Knoten müssen für die Kommunikation zwischen den Knoten dieselbe Portnummer verwenden.
-q	Nein	61616	Der Port für die Warteschlange von clusterweiten Ereignissen. Der Standardwert ist 61616.
-d	Ja	/path/to/looker-db.yml	Der Pfad zur Datei mit den Anmeldedaten für die Looker-Anwendungsdatenbank.
--shared-storage-dir	Ja	/path/to/mounted/shared/storage	Die Option sollte auf das oben auf dieser Seite eingerichtete freigegebene Verzeichnis verweisen, das die Verzeichnisse looker/model und looker/models-user-* enthält.

Hinweis: Das Startup-Flag --clustered sollte keinen Wert enthalten.

Beispiel für LOOKERARGS und Angabe von Datenbankanmeldedaten

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

Sie könnten Looker beispielsweise Folgendes mitteilen:

• Wenn Sie die Datei looker-db.yml für die Datenbankanmeldedaten verwenden möchten,
• dass es sich um einen gruppierten Knoten handelt und
• dass die anderen Knoten des Clusters diesen Host über die IP-Adresse 10.10.10.10 kontaktieren sollen.

Sie würden Folgendes angeben:

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

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

Die Datei looker-db.yml würde die Datenbankanmeldedaten enthalten, 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, muss die Datei looker-db.yml außerdem Folgendes enthalten:

ssl: true

Hinweis:Sie müssen eine Kopie der Datei mit den Anmeldedaten im freigegebenen Speicher und auf jedem Knoten im Cluster speichern.

Hinweis:Beachten Sie die Best Practices für die Sicherheit, wenn Sie Anmeldedaten in einer Datei speichern. Idealerweise legen Sie die Dateiberechtigungen für looker-db.yml auf 600 fest. Die Datei sollte dem Linux-Nutzerkonto gehören, unter dem die Looker-Anwendung ausgeführt wird. Diese Datei sollte niemals in ein Git-Repository eingecheckt werden.

Wenn Sie die Konfiguration nicht in der Datei looker-db.yml auf der Festplatte speichern möchten, können Sie die Umgebungsvariable LOOKER_DB so konfigurieren, dass sie eine Liste von Schlüsseln und 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 Git-SSH-Bereitstellungsschlüssel speichert, hängt davon ab, in welcher Version das Projekt erstellt wurde:

• Bei Projekten, die vor Looker 4.8 erstellt wurden, werden die Bereitstellungsschlüssel im integrierten 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 verwalteten Verzeichnis gespeichert: ~/looker/deploy_keys/PROJECT_NAME.

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 eine neue Looker-Version aktualisieren

Updates können Schemaänderungen an der internen Datenbank von Looker umfassen, die nicht mit früheren Versionen von Looker kompatibel sind. Es gibt zwei Methoden zum Aktualisieren von Looker.

Sicherere Methode

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

Schnellere Methode

Hinweis :Mit dieser Methode werden Ausfallzeiten verringert. Allerdings gehen alle Änderungen verloren, die zwischen dem Erstellen des Replikats und dem Verweisen des Proxyservers auf die neuen Knoten vorgenommen wurden. Wenn während der Umstellung beispielsweise Nutzer hinzugefügt oder Looks erstellt werden, werden diese Änderungen möglicherweise nicht in der neuen Anwendungsdatenbank erfasst.

So aktualisieren Sie mit dieser schnelleren, aber weniger vollständigen Methode:

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. Anschließend können Sie die alten Knoten beenden.