Looker-Clustering

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

Überblick

Vom Kunden gehostete Bereitstellungen von Looker können auf einem einzelnen Knoten oder in Cluster ausgeführt werden:

• Bei einer Looker-Anwendung mit einem einzelnen Knoten (Standardkonfiguration) werden alle Dienste, aus denen die Looker-Anwendung besteht, auf einem einzigen Server ausgeführt.
• Eine Looker-Clusterkonfiguration 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 Looker-Clusteranwendung 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

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 Speicher für den Looker-Prozess zu erhöhen.

Alternativen für das Load-Balancing

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 richtig für seine Arbeitslast skaliert ist.

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

Bei Konfigurationen mit bis zu 50 Nutzern, die Looker wenig verwenden, empfiehlt Looker, einen einzelnen Server auf dem Äquivalent einer großen AWS EC2-Instanz auszuführen (M4.large: 8 GB RAM, 2 CPU-Kerne). Prüfen Sie bei Konfigurationen mit mehr oder vielen aktiven Powerusern, ob die CPU stark ansteigt oder ob Nutzer eine langsame Anwendung feststellen. Wenn ja, verschieben Sie Looker auf einen größeren Server oder führen Sie eine Looker-Clusterkonfiguration aus.

Verbesserte Verfügbarkeit/Failover

Wenn Sie Looker in einer Cluster-Umgebung ausführen, können Sie Ausfallzeiten im Falle eines Ausfalls minimieren. Hochverfügbarkeit ist besonders wichtig, wenn die Looker API in Kerngeschäftssystemen verwendet wird oder wenn Looker in kundenseitige Produkte eingebettet ist.

In einer Looker-Clusterkonfiguration leitet ein Proxyserver oder Load-Balancer Traffic um, wenn festgestellt wird, dass ein Knoten ausgefallen ist. Looker kümmert sich automatisch um Knoten, die den Cluster verlassen und dem Cluster 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
• Richtige Version der JAR-Dateien der Looker-Anwendung

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

MySQL-Anwendungsdatenbank

Looker verwendet eine Anwendungsdatenbank (häufig als interne Datenbank bezeichnet), in der Anwendungsdaten gespeichert werden. Wenn Looker als Anwendung mit einem einzelnen Knoten ausgeführt wird, wird normalerweise eine speicherinterne HyperSQL-Datenbank verwendet.

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

• Für die Anwendungsdatenbank für geclusterte Looker-Instanzen wird nur MySQL unterstützt. Amazon Aurora und MariaDB werden nicht unterstützt.
• Die MySQL-Versionen 5.7 und 8.0 und höher werden 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 die Wartung und Sicherungen dieser Datenbank nicht. Da die Datenbank jedoch fast alle Konfigurationsdaten der Looker-Anwendung hostet, sollte sie als Hochverfügbarkeitsdatenbank bereitgestellt und mindestens einmal 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 in der Lage sein, einander und die Looker-Anwendungsdatenbank zu erreichen. Die Standardports sind auf dieser Seite unter Ports für die Kommunikation durch die Knoten öffnen aufgeführt.

Load-Balancer

Zum Ausgleichen der Last oder zum Umleiten 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 Knotenfehler muss der Load-Balancer so konfiguriert sein, 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 solches Beispiel ist der Amazon Classic ELB. 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). Looker verwendet das freigegebene Dateisystem als Repository für verschiedene Informationen, die von allen Knoten im Cluster verwendet werden.

Hinweis: Zum Installieren von Anwendungen und Tools aus dem Looker Marketplace muss ein freigegebenes (Netzwerk-)Dateisystem verwendet werden.

Looker-Anwendung (ausführbare JAR-Datei)

Sie müssen eine JAR-Datei für die Looker-Anwendung in der Version 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-Kern-JAR-Datei und eine JAR-Datei für Looker-Abhängigkeiten. Wenn Sie Looker 6.18 oder höher installieren oder auf eine neue Version aktualisieren, müssen Sie beide JAR-Dateien herunterladen.

Looker empfiehlt dringend, auf jedem Knoten in einem Cluster dieselbe Looker-Release- und Patchversion auszuführen, wie im Abschnitt Looker auf den Knoten starten auf dieser Seite beschrieben.

Cluster einrichten

Die folgenden Aufgaben sind erforderlich:

1. Looker installieren
2. MySQL-Anwendungsdatenbank einrichten
3. Freigegebenes Dateisystem einrichten
4. Geben Sie das SSH-Schlüssel-Repository frei (je nach Situation).
5. Ports öffnen, über die die Knoten kommunizieren können
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

Bei einer Looker-Clusterkonfiguration muss die Anwendungsserverdatenbank 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 unbedingt Ihr Looker-Verzeichnis. Die Migration kann nur von einer HyperSQL-Datenbank 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 Migration zu MySQL.

Freigegebenes Dateisystem einrichten

Nur bestimmte Dateitypen – 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 auf das Looker-Nutzerkonto zugreifen kann.
2. Melden Sie sich auf dem Server für das freigegebene Dateisystem beim Looker-Benutzerkonto an.
3. Wenn Looker gerade ausgeführt wird, beenden Sie die Looker-Konfiguration.
4. Wenn Sie zuvor Clustering mit inotify Linux-Skripts ausgeführt 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. Stellen Sie sicher, dass er für die automatische Bereitstellung auf jedem Knoten konfiguriert ist und dass der Looker-Benutzer Lese- und Schreibzugriff darauf 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, in 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 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 sind, hat sie möglicherweise jemand 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 Dateisystemcluster 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 müssen Sie das Verzeichnis $HOME/.ssh des Looker-Nutzers ändern. Das kann die Anmeldung und die Behebung von Fehlern in der Konfiguration erschweren. Bevor Sie diese Schritte ausführen, benötigen Sie Zugriff auf ein anderes Konto, das su auf das Looker-Nutzerkonto zugreifen kann.

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 für die Berechtigungen „700“ festgelegt ist. Verzeichnisse über dem ssh-share-Verzeichnis (z. B. /mnt und /mnt/looker-share) dürfen nicht weltbeschreibbar oder gruppenbeschreibbar sein.

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

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

3. Sichern Sie für jeden Knoten die vorhandene 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 unbedingt für jeden Knoten aus.

Ports öffnen, über die die Knoten kommunizieren können

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 mithilfe der 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.

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

Verfügbare Start-Flags

Die folgende Tabelle zeigt 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		Flag hinzufügen, um anzugeben, dass dieser Knoten im Clustermodus ausgeführt wird.
-H oder --hostname	Ja	10.10.10.10	Der Hostname, mit dem andere Knoten diesen Knoten kontaktieren, z. B. die IP-Adresse des Knotens oder sein System-Hostname. 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 von clusterweiten Ereignissen in die Warteschlange. Der Standardwert ist 61616.
-d	Ja	/path/to/looker-db.yml	Der Pfad zu der Datei mit den Anmeldedaten für die Looker-Anwendungsdatenbank.
--shared-storage-dir	Ja	/path/to/mounted/shared/storage	Die Option sollte auf die oben auf dieser Seite bereitgestellte Einrichtung des freigegebenen Verzeichnisses verweisen, die die Verzeichnisse looker/model und looker/models-user-* enthält.

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

Beispiel für LOOKERARGS und Angabe von Datenbankanmeldedaten

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

Sie können Looker beispielsweise Folgendes mitteilen:

• So verwenden Sie die Datei mit dem Namen looker-db.yml als Datenbankanmeldedaten:
• dass es sich um einen geclusterten Knoten handelt.
• dass die anderen Knoten des Clusters diesen Host über die IP-Adresse 10.10.10.10 kontaktieren sollten.

In diesem Fall würden Sie Folgendes angeben:

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

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

Die Datei looker-db.yml würde die Anmeldedaten für die Datenbank 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, erfordert die Datei looker-db.yml außerdem Folgendes:

ssl: true

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

Hinweis: Beachten Sie die Sicherheitshinweise aus Best Practices, wenn Sie Anmeldedaten in einer Datei speichern. Legen Sie im Idealfall die looker-db.yml-Dateiberechtigungen auf 600 fest. Das ist der Inhaber des Linux-Nutzerkontos, in 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 dem 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 von Schlüsseln/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 nativen SSH-Verzeichnis des Servers gespeichert: ~/.ssh.
• Bei Projekten, die in Looker 4.8 oder höher erstellt wurden, werden die Bereitstellungsschlüssel im 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 eine neue Looker-Version aktualisieren

Aktualisierungen können Schemaänderungen in 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 wird die Ausfallzeit verringert, jedoch 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 aktualisieren Sie mit dieser schnelleren, aber weniger vollständigen Methode:

1. Erstellen Sie ein Replikat der Looker-Anwendungsdatenbank.
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.