Looker-Clustering

In dieser Anleitung wird die empfohlene Methode zum Erstellen einer Looker-Clusterkonfiguration für vom Kunden gehostete Instanzen erläutert.

Überblick

Vom Kunden gehostete Bereitstellungen von Looker können mit einem Knoten oder geclustert ausgeführt werden:

• Eine Looker-Anwendung mit einem Knoten, die Standardkonfiguration, verfügt über 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 in der Regel Datenbankserver, Lastenausgleichsmodule 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 ein Unternehmen Looker als Cluster ausführen sollte:

• Load Balancing
• Verbesserte Verfügbarkeit und Failover

Abhängig von den Skalierungsproblemen ist ein geclustertes 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 zu erhöhen, auf dem Looker ausgeführt wird. Looker empfiehlt, eine detaillierte Leistungsüberwachung für die Arbeitsspeicher- und CPU-Auslastung einzurichten, um sicherzustellen, dass der Looker-Server die richtige Größe für die 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.

Für Konfigurationen mit bis zu 50 Benutzern, die Looker nur wenig nutzen, empfiehlt Looker, einen einzelnen Server auf der Basis einer großen AWS EC2-Instanz auszuführen (M4.large: 8 GB RAM, 2 CPU-Kerne). Achten Sie bei Konfigurationen mit mehr Nutzern oder vielen aktiven Powerusern darauf, ob die CPU-Auslastung ansteigt oder ob die Anwendung langsam ist. Wenn ja, verschieben Sie Looker auf einen größeren Server oder führen Sie eine Looker-Clusterkonfiguration aus.

Verbesserte Verfügbarkeit/Failover

Die Ausführung von Looker in einer geclusterten Umgebung kann die Ausfallzeit im Falle eines Ausfalls verringern. Hochverfügbarkeit ist besonders wichtig, wenn die Looker-API in zentralen Geschäftssystemen verwendet wird oder wenn Looker in kundenseitige Produkte eingebettet ist.

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

Erforderliche Komponenten

Die folgenden Komponenten sind für eine Looker-Clusterkonfiguration erforderlich:

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

Das folgende Diagramm zeigt, wie die Komponenten interagieren. Auf übergeordneter Ebene verteilt ein Lastenausgleichsmodul den Netzwerkverkehr auf geclusterte Looker-Knoten. Die Knoten kommunizieren jeweils mit einer freigegebenen MySQL-Anwendungsdatenbank, einem freigegebenen Speicherverzeichnis und den Git-Servern für jedes LookML-Projekt.

MySQL-Anwendungsdatenbank

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

In einer Looker-Clusterkonfiguration muss die Looker-Instanz jedes Knotens auf eine freigegebene Transaktionsdatenbank verweisen (die gemeinsame Anwendung oder die interne Datenbank). Die Anwendungsdatenbank für geclusterte Looker-Cluster wird wie folgt unterstützt:

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

Hinweis: Zur Verbesserung der Leistung und Redundanz wird eine Lesereplikatdatenbank empfohlen. Die Lesereplikatdatenbank muss keine MySQL-Datenbank sein.

Looker verwaltet nicht die Wartung und Sicherungen dieser Datenbank. 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 erreichbar sein. Die Standardports sind auf dieser Seite unter Ports für die Kommunikation mit Knoten öffnen aufgeführt.

Load-Balancer

Zum Ausgleichen der Last oder Weiterleitung von Anfragen 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 Knotenausfall 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 verwendet werden kann. Der Amazon Classic ELB ist ein solches Beispiel. Darüber hinaus sollte der Load-Balancer ein langes Zeitlimit (3.600 Sekunden) haben, um zu verhindern,dass Abfragen abgebrochen werden.

Freigegebenes Dateisystem

Sie müssen ein POSIX-konformes freigegebenes Dateisystem verwenden (z. B. NFS, AWS EFS, Gluster, BeeGFS, Lustre usw.). 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 Looker-Anwendungs-JAR-Datei mit der Version 3.56 oder höher verwenden.

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

Looker empfiehlt dringend, für jeden Knoten in einem Cluster dieselbe Looker-Version und dieselbe Patchversion auszuführen, wie unter Looker auf den Knoten starten auf dieser Seite beschrieben.

Cluster einrichten

Folgende 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 Knotenkommunikation ö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 der 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 bereits eine 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 unbedingt Ihr Looker-Verzeichnis. Der Migrationsprozess kann nur von einer HyperSQL-Datenbank zu einer MySQL-Datenbank erfolgen und nicht umgekehrt.

Auf der Dokumentationsseite Zu MySQL migrieren finden Sie Informationen zum Sichern von Looker und zum anschließenden Migrieren der Anwendungsdatenbank von HyperSQL zu MySQL.

Freigegebenes Dateisystem einrichten

Nur bestimmte Dateitypen – Modelldateien, Bereitstellungsschlüssel, Plug-ins und möglicherweise App-Manifestdateien – 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 haben, das su auf das Looker-Nutzerkonto kann.
2. Melden Sie sich auf dem Server für das freigegebene Dateisystem im Looker-Nutzerkonto an.
3. Wenn Looker ausgeführt wird, fahren Sie Ihre Looker-Konfiguration herunter.
4. Wenn Sie zuvor Clustering mit inotify-Linux-Skripts durchgeführt haben, halten Sie diese Skripts an, 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 er für die automatische Bereitstellung auf jedem Knoten konfiguriert ist und der Looker-Benutzer Lese- und Schreibzugriff auf diesen Knoten hat. Im folgenden Beispiel heißt die Netzwerkfreigabe /mnt/looker-share.

6. Kopieren Sie die Bereitstellungsschlüssel auf einem Knoten und verschieben Sie Ihre Plug-ins sowie die Verzeichnisse looker/models und looker/models-user-*, in denen Ihre Modelldateien gespeichert sind, auf Ihre 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 $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 jemand sie möglicherweise direkt dem $HOME/looker/looker-Shell-Skript hinzugefügt.

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

SSH-Schlüssel-Repository freigeben

• Sie erstellen einen freigegebenen Dateisystem-Cluster aus einer vorhandenen Looker-Konfiguration und
• Sie haben Projekte, die in Looker 4.6 oder niedriger erstellt wurden.

Hinweis: Für die folgende Vorgehensweise müssen Sie das Verzeichnis $HOME/.ssh des Looker-Nutzers ändern. Dies kann das Anmelden und Beheben von Fehlern in der Konfiguration erschweren. Bevor Sie diese Schritte ausführen, benötigen Sie Zugriff auf ein anderes Konto, mit dem Sie su auf das Looker-Nutzerkonto anwenden können.

Richten Sie das SSH-Schlüssel-Repository zur Freigabe ein:

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

   Prüfen Sie, ob das Verzeichnis ssh-share dem Looker-Nutzer gehört und die Berechtigungen 700 haben. Achten Sie außerdem darauf, dass Verzeichnisse oberhalb des Verzeichnisses ssh-share (z. B. /mnt und /mnt/looker-share) weder von allen noch gruppenbeschreibbar 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 durch.

Ports für die Knotenkommunikation öffnen

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

Die Standardports, die zwischen Clusterknoten offen sein müssen, sind 1551 und 61616. Diese Ports können mithilfe der hier aufgeführten Start-Flags konfiguriert werden. Wir empfehlen dringend, den Netzwerkzugriff auf diese Ports zu beschränken, damit nur Traffic zwischen den Clusterhosts zugelassen wird.

Looker auf den Knoten starten

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

Hinweis: Jeder Knoten in einem Cluster muss dieselbe Looker-Version und dieselbe Patchversion ausführen.

Verfügbare Start-Flags

In der folgenden Tabelle sind die verfügbaren Start-Flags aufgeführt, einschließlich der Flags, die zum Starten oder Verbinden eines Clusters erforderlich sind:

Flag	Erforderlich/Optional?	Werte	Zweck
--clustered	Yes		Flag hinzufügen, um anzugeben, dass dieser Knoten im geclusterten Modus ausgeführt wird.
-H oder --hostname	Yes	10.10.10.10	Der Hostname, mit dem andere Knoten diesen Knoten kontaktieren, z. B. die IP-Adresse des Knotens oder den Systemhostnamen des Knotens. 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 dieselbe Portnummer für die Kommunikation zwischen Knoten verwenden.
-q	Nein	61616	Der Port zum Einstellen clusterweiter Ereignisse in die Warteschlange. Der Standardwert ist 61616.
-d	Yes	/path/to/looker-db.yml	Der Pfad zur Datei mit den Anmeldedaten für die Looker-Anwendungsdatenbank.
--shared-storage-dir	Yes	/path/to/mounted/shared/storage	Die Option sollte auf die Einrichtung des freigegebenen Verzeichnisses weiter oben auf dieser Seite verweisen, das die Verzeichnisse looker/model und looker/models-user-* enthält.

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

Beispiel für LOOKERARGS und Angeben von Datenbankanmeldedaten

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

Beispielsweise könnten Sie Looker mitteilen:

• So verwenden Sie die Datei looker-db.yml für ihre Datenbankanmeldedaten:
• dass es sich um einen geclusterten Knoten handelt
• dass die anderen Knoten des Clusters diesen Host unter der IP-Adresse 10.10.10.10 kontaktieren sollen.

Sie geben Folgendes an:

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

Hinweis: Geben Sie die richtige IP-Adresse für Ihren Knoten an.

Die Datei looker-db.yml enthält dann die Anmeldedaten für die Datenbank, z. B.:

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

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

ssl: true

Hinweis: Sie müssen eine Kopie Ihrer Anmeldedatendatei im freigegebenen Speicher und auf jedem Knoten im Cluster speichern.

Hinweis: Beachten Sie beim Speichern von Anmeldedaten in einer Datei die Sicherheitsaspekte mit Best Practices. Legen Sie idealerweise die Berechtigungen für die Datei looker-db.yml auf 600 fest. Sie gehören dem Linux-Nutzerkonto, 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 einem Laufwerk speichern möchten, können Sie die Umgebungsvariable LOOKER_DB so konfigurieren, dass sie für jede Zeile in der Datei looker-db.yml eine Liste mit Schlüsseln und Werten 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 vom Release ab, in dem 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 (~/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 eine neue Looker-Version aktualisieren

Aktualisierungen können Schemaänderungen in der internen Datenbank von Looker umfassen, die mit früheren Versionen von Looker nicht kompatibel wären. Es gibt zwei Methoden, Looker zu aktualisieren.

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 wird die Ausfallzeit verringert, allerdings gehen alle Änderungen verloren, die zwischen dem Erstellen des Replikats und dem Verweisen des Proxyservers auf die neuen Knoten vorgenommen wurden. Wenn beispielsweise während der Umstellung Nutzer hinzugefügt oder Looks erstellt werden, werden diese Änderungen möglicherweise nicht in der neuen Anwendungsdatenbank erfasst.

So führen Sie eine Aktualisierung mit dieser schnelleren, aber weniger vollständigen Methode durch:

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.