Looker clustern

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

Übersicht

Von Kunden gehostete Bereitstellungen von Looker können auf einem einzelnen Knoten oder geclustert ausgeführt werden:

• Bei einer Looker-Anwendung mit einem einzelnen Knoten, der Standardkonfiguration, werden alle Dienste, aus denen sich die Looker-Anwendung zusammensetzt, auf einem einzelnen 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 ein Unternehmen Looker als Cluster ausführen möchte:

• Load-Balancing
• Verbesserte Verfügbarkeit und Failover

Je nach Skalierungsproblemen ist eine geclusterte Looker-Konfiguration möglicherweise nicht die richtige Lösung. Wenn beispielsweise eine kleine Anzahl großer Abfragen den Systemspeicher aufbraucht, besteht die einzige Lösung darin, den verfügbaren Speicher für den Looker-Prozess zu erhöhen.

Alternativen zum Load-Balancing

Bevor Sie Looker mit Load-Balancing ausführen, sollten Sie den Speicher und möglicherweise die Anzahl der CPUs eines einzelnen Servers erhöhen, auf dem Looker ausgeführt wird. Looker empfiehlt, eine detaillierte Leistungsüberwachung für die Speicher- und CPU-Auslastung einzurichten, um sicherzustellen, dass der Looker-Server für seine Arbeitslast richtig dimensioniert ist.

Für große Abfragen ist mehr Speicher erforderlich, um die Leistung zu verbessern. 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, einen einzelnen Server mit der Leistung einer großen AWS EC2-Instanz (M4.large: 8 GB RAM, 2 CPU-Kerne) auszuführen. Bei Konfigurationen mit mehr Nutzern oder vielen aktiven Power-Nutzern sollten Sie prüfen, ob die CPU-Auslastung ansteigt oder ob Nutzer eine Verlangsamung der Anwendung bemerken. Wenn dies der Fall ist, 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 geclusterten Umgebung ausführen, können Sie Ausfallzeiten im Falle eines Ausfalls reduzieren. Hochverfü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
• Geeignete Version der JAR-Dateien der Looker-Anwendung

Das folgende Diagramm zeigt, wie die Komponenten interagieren. Ein Load-Balancer verteilt den Netzwerk-Traffic zwischen geclusterten 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 einzelnen Knoten ausgeführt wird, wird normalerweise eine In-Memory-HyperSQL-Datenbank verwendet.

In einer geclusterten Looker-Konfiguration muss die Looker-Instanz jedes Knotens auf eine freigegebene Transaktionsdatenbank verweisen (die freigegebene Anwendungs- oder interne Datenbank). Die Unterstützung für die Anwendungsdatenbank für geclusterte Looker-Konfigurationen 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 Lesereplikatdatenbank wird empfohlen, um die Leistung und Redundanz zu verbessern. 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 enthält, sollte sie als hochverfügbare Datenbank 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 den Traffic an jeden Looker-Knoten weiterzuleiten. Der Load-Balancer führt Systemdiagnosen durch. Im Falle eines Knotenausfalls muss der Load-Balancer so konfiguriert sein, dass er den Traffic an die verbleibenden fehlerfreien Knoten weiterleitet.

Achten Sie bei der Auswahl und Konfiguration 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, um zu verhindern,dass Abfragen beendet werden.

Freigegebenes Dateisystem

Sie müssen ein POSIX-kompatibles 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.

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 der Looker-Anwendung mit Looker 3.56 oder höher verwenden.

Hinweis: Ab Looker 6.18 wurde die Looker-JAR-Datei in zwei separate JAR-Dateien aufgeteilt: die Looker-Core-JAR-Datei und eine JAR-Datei mit Looker-Abhängigkeiten. Wenn Sie Looker 6.18 oder höher installieren oder 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 von Kunden gehostete Instanzen.

MySQL-Anwendungsdatenbank einrichten

Für eine geclusterte 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 die neue freigegebene MySQL-Anwendungsdatenbank migrieren.

Hinweis: Sichern Sie das Looker-Verzeichnis. Die Migration ist nur von einer HyperSQL-Datenbank zu einer MySQL-Datenbank möglich, 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 gehören in das freigegebene Dateisystem: Modelldateien, Bereitstellungsschlüssel, Plug-ins und möglicherweise Anwendungsmanifestdateien. 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, mit dem Sie su zum Looker-Nutzerkonto ausführen können.
2. Melden Sie sich auf dem Server für das freigegebene Dateisystem im Looker-Nutzerkonto an.
3. Wenn Looker ausgeführt wird, fahren Sie die Looker-Konfiguration herunter.
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 sie so konfiguriert ist, dass sie auf jedem Knoten automatisch bereitgestellt wird, und dass der Looker-Nutzer Lese- und Schreibzugriff darauf hat. Im folgenden Beispiel heißt die Netzwerkfreigabe /mnt/looker-share.

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

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

   Hinweis: Die 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 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 durch Updates beeinträchtigt werden. Wenn LOOKERARGS nicht in dieser Datei aufgeführt ist, hat jemand sie möglicherweise direkt zum Shell-Skript $HOME/looker/looker 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 die folgende Vorgehensweise muss das Verzeichnis des Looker-Nutzers geändert werden.$HOME/.ssh Dies kann es erschweren, sich anzumelden und Fehler zu beheben, wenn in der Konfiguration Fehler auftreten. Bevor Sie diese Schritte ausführen, müssen Sie Zugriff auf ein anderes Konto haben, mit dem Sie su zum Looker-Nutzerkonto ausführen können.

So richten Sie das freigegebene SSH-Schlüssel-Repository ein:

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. Außerdem dürfen Verzeichnisse über dem ssh-share Verzeichnis (z. B. /mnt und /mnt/looker-share) nicht für alle oder für Gruppen beschreibbar sein.

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

Geclusterte Looker-Knoten kommunizieren über HTTPS mit selbstsignierten 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 zu beschränken, damit Traffic nur zwischen den Clusterhosts möglich ist.

Looker auf den Knoten starten

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

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

Verfügbare Start-Flags

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

Flag	Erforderlich/Optional?	Werte	Zweck
--clustered	Ja		Fügen Sie das Flag hinzu, um anzugeben, dass dieser Knoten im geclusterten Modus 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 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 freigegebene Verzeichnis verweisen, das zuvor auf dieser Seite eingerichtet wurde und die Verzeichnisse looker/model und looker/models-user-* enthält.

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

Beispiel für LOOKERARGS und Angabe von Anmeldedaten für die Datenbank

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

Beispielsweise können Sie Looker Folgendes mitteilen:

• Die Datei looker-db.yml für die Anmeldedaten der Datenbank verwenden,
• dass es sich um einen geclusterten Knoten handelt und
• dass die anderen Knoten des Clusters diesen Host über die IP-Adresse 10.10.10.10 kontaktieren sollen.

Geben Sie 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 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 für Ihre MySQL-Datenbank eine SSL-Verbindung erforderlich ist, muss die Datei looker-db.yml auch 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 Berechtigungen für die Datei looker-db.yml auf 600 fest und weisen sie dem Linux-Nutzerkonto zu, 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 von der Releaseversion ab, in der das Projekt erstellt wurde:

• Bei Projekten, die vor Looker 4.8 erstellt wurden, werden die Bereitstellungsschlüssel im integrierten SSH-Verzeichnis des Servers gespeichert: ~/.ssh.
• 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-Releaseversion aktualisieren

Updates können Schemasänderungen an der internen Datenbank von Looker umfassen, die nicht mit früheren Versionen von Looker kompatibel sind. Es gibt zwei Methoden, um 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: Bei dieser Methode wird die Ausfallzeit reduziert, aber 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 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.